निर्देशिका के एलएस में प्रश्न चिह्न। IO त्रुटियाँ भी

44

क्या किसी ने इसे पहले कभी देखा है? मुझे अपने सर्वर पर एक छापे 5 मिला है और जो भी कारण इसे दिखाने लगा है:

jason @ box2: / mnt / raid1 / cra $ ls -alh
ls: e6eacc985fea729b2d5bc74078632738 पर नहीं जा सकता
ls: 257ad35ee0b12a714530c30dccf9210f एक्सेस नहीं कर सकता: इनपुट / आउटपुट त्रुटि
कुल ०
drwxr-xr-x 5 रूट रूट 123 2009-08-19 16:33।
drwxr-xr-x 3 रूट रूट 16 2009-08-14 17:15 ।।
?????????? ? ? ? ? ? 257ad35ee0b12a714530c30dccf9210f
drwxr-xr-x 3 रूट रूट 57 2009-08-19 16:58 9c89a78e93ae6738e01136db9153361b
?????????? ? ? ? ? ? e6eacc985fea729b2d5bc74078632738

Md5 स्ट्रिंग्स वास्तविक निर्देशिका नाम हैं और त्रुटि का हिस्सा नहीं हैं। प्रश्न चिह्न विषम हैं, और जब आप इसका उपयोग / हटाने / आदि का प्रयास करते हैं, तो प्रश्न चिह्न वाली कोई भी निर्देशिका एक io त्रुटि को फेंक देती है।

मैं "व्यस्त" होने के कारण ड्राइव को umount करने में असमर्थ था। सर्वर को रिबूट करते हुए इसे "ठीक" कर दिया गया लेकिन यह शटडाउन पर कुछ छापे वाली त्रुटियों को फेंक रहा था। मैंने दो RAID 5 सरणियों को कॉन्फ़िगर किया है और दोनों ने यादृच्छिक फ़ाइलों पर ऐसा करना शुरू कर दिया है। दोनों निम्नलिखित विन्यास का उपयोग कर रहे हैं:

mkfs.xfs -l size = 128m -d agcount = 32
माउंट -t xfs -o noatime, logbufs = 8

कुछ भी नहीं फैंसी, लेकिन इस बॉक्स के लिए एक अनुकूलित विन्यास का हिस्सा है। हम ड्राइव को विभाजित नहीं कर रहे हैं और यह संभव मुद्दे के रूप में सुझाया गया था। क्या यह अपराधी हो सकता है?

linux debian filesystems

मैंने इन प्रश्न चिह्नों को देखा है जब ऑटोफोंस ने एक निर्देशिका बढ़ते हुए मुद्दे रखे थे। ऑटोफोटो को बंद करने से मुझे निर्देशिका को हटाने और मैन्युअल रूप से माउंट करने का प्रयास करने की अनुमति मिली, जो दूरस्थ सर्वर पर अनुमतियों की त्रुटि की ओर इशारा करती है।

— पेस

39

मुझे इसी तरह की समस्या थी क्योंकि मेरी निर्देशिका ने (r) पढ़ा था लेकिन निष्पादन (x) अधिकारों का नहीं। मेरी निर्देशिका लिस्टिंग से पता चला:

myname@srv:/home$ ls -l service/mail/
ls: cannot access service/mail/001_SERVICE INBOX: Permission denied
total 0
-????????? ? ? ? ?                ? 001_SERVICE INBOX
d????????? ? ? ? ?                ? 01_CURRENT SERVICE

मेल डायरेक्टरी में r बिट सेट था, लेकिन वह x नहीं जिसे आपको लिस्टिंग या खोज और एक्सेस की आवश्यकता है। sudo chmod -R g+x mailइस समस्या का समाधान कर रहे हैं ।

— user65174
स्रोत

4

'sudo chmod -R g + x मेल' और फिर chmod +x mailमेरी समस्या हल, धन्यवाद!

— ग्लीबम

6

क्या आपके यदि lsरिटर्न no such file or directoryका एक समूह के साथ ?????विशेषाधिकार / अधिकार क्षेत्र में?

— केविन मेरेडिथ

11

lsआउटपुट में प्रश्न चिह्न केवल यह दर्शाता है कि यह stat()निर्देशिका प्रविष्टि नहीं कर सकता है । आप उन्हें देख सकते हैं यदि आप lsएक निर्देशिका जिसके लिए आपके पास r (ead) है, लेकिन x (खोज) की अनुमति नहीं है। हालाँकि उस स्थिति में यह I / O त्रुटि की रिपोर्ट नहीं करेगा ।

आपके मामले में ऐसा लगता है कि डिस्क त्रुटि या संभवतया फ़ाइल सिस्टम भ्रष्टाचार है। /var/log/messagesया dmesgआगे के विवरणों को प्रकट करने की संभावना है।

— mark4o
स्रोत

10

पढ़ने का उल्लेख करने वाले उत्तर, लेकिन निष्पादित या स्टेट () सही नहीं हैं। लेकिन इसका एक सामान्य कारण है (भ्रष्टाचार के अलावा) जो मुझे कुछ समय के लिए काटता है और आपके प्रश्न का आईओ त्रुटियों के साथ अच्छी तरह मेल खाता है। यदि आप अनुचित रूप से किसी फ़ाइल सिस्टम को माउंट करते हैं, तो उस फाइल सिस्टम का माउंट पॉइंट प्रश्नवाचक चिह्न के साथ दिखाई दे सकता है। यदि आप इन्हें देख रहे हैं, जहाँ आपने अभी-अभी एक नई फाइलसिस्टम माउंट करने की कोशिश की है, तो भ्रष्टाचार और fsck के बारे में चिंता करने से पहले निम्न प्रयास करें।

$ sudo umount /mnt/raid1/cra/257ad35ee0b12a714530c30dccf9210f
$ ls -alh /mnt/raid1/cra

आपको प्रश्न चिह्नों के बजाय 257ad35ee0b12a714530c30dccf9210f फ़ोल्डर को अनुमतियों और विशेषताओं के साथ देखना चाहिए। यदि हां, तो अपने माउंट कमांड या / etc / fstab फ़ाइल के लिए अन्य विकल्पों की खोज करें। यदि नहीं, तो शायद अन्य उत्तरों को पढ़ने का समय है, बैकअप जो आप कर सकते हैं, और एक fsck चलाएं।

— mightypile
स्रोत

यह मेरी समस्या थी

— एंडोलिथ

5

मानवीय रूप से जल्द से जल्द एक बैकअप लें, यदि केवल इतना है कि यदि आप इसे किसी और संभावित नुकसान की मरम्मत करने की कोशिश करते समय गड़बड़ करते हैं तो आप मूल कम-टूटी हुई स्थिति में वापस जा सकते हैं। बैकअप लेने के बाद, आप यह देखने के लिए fsck चला सकते हैं कि क्या उसे लगता है कि कोई समस्या है।

— स्टीवन श्लैंस्कर
स्रोत

मेरे मामले में यह पहले से ही बैकअप है।

— पाओलो

1

हो सकता है कि फिल्म के नाम में सिर्फ अजेय अक्षर हों। Emacs के साथ फ़ाइल नामों की जाँच करने का प्रयास करें DirEd:

http://www.cs.utah.edu/dept/old/texinfo/emacs19/emacs_32.html

— व्लादिस्लाव रस्त्रुसनी
स्रोत

1

हमारे पास एक दूषित फ़ाइल सिस्टम (reiserfs) के साथ एक सर्वर था और इसने फ़ाइल नाम को छोड़कर सभी विशेषताओं के लिए प्रश्न चिह्न के साथ निर्देशिका प्रविष्टियाँ उत्पन्न कीं। हमारे मामले में, फ़ाइल नाम अप्रभावित थे।

साथ ही, खाली जगह को गलत बताया जा रहा था। प्रयोग से du -sh /*हम केवल 30G के बारे में ही जान सकते हैं, लेकिन उपयोग में 200G से अधिक की ड्राइव बताई जा रही है।

shutdown -rF nowफ़ाइल-सिस्टम जांच के लिए सर्वर के साथ रिबूट करने से काम नहीं चला। मुझे एकल-उपयोगकर्ता मोड में रीबूट करना और चलाना था:

fsck.reiserfs --rebuild-tree /dev/sda3

यह लगभग काम कर गया। यह कुछ पास से होकर गुजरा, फिर ताला लगा दिया गया। ओएस को फिर से स्थापित करना था।

अपने बैकअप बनाए रखें!

1

मैंने यह भी देखा है जब autofs चल रहा है, लेकिन autofs निर्देशिका को माउंट नहीं कर सकता है। तो फिर यह पता लगाने के लिए कि यह उस निर्देशिका को माउंट नहीं कर सकता है जिसे मैंने ऑटोफ़्स को अक्षम किया है और निर्देशिका को मैन्युअल रूप से माउंट करने की कोशिश की है (इसने मुझे निर्देशिका को हटाने की अनुमति दी है)। मैंने निर्देशिका को मैन्युअल रूप से माउंट करने का प्रयास किया और पाया कि अनुमतियाँ त्रुटि थी। इसे ठीक करने के बाद, निर्देशिका फिर से सामान्य हो गई।

— गति
स्रोत

1

उदाहरण के लिए सर्वर पर अन्य चल रही प्रक्रियाओं के लिए देखें rsync

[root@server upload]# ls -la
ls: cannot access .3bfb3dc5-cb55-435f-8e23-2afcab2c6873_image4993891600240007749.jpg.bV6VTV: No such file or directory
total 194496
drwxr-x--- 2 gx apache    1382 Jan 11 10:36 .
drwxr-x--- 3 gx apache       3 Jan 11 10:29 ..
-rw-r--r-- 1 gx apache   94850 Dec 10  2015 37d355b9-210d-45df-8061-968ea5cb9f31_mob.jpg
...
-rw-r--r-- 1 gx apache   10864 Jul 24  2015 3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png
-rw-r--r-- 1 gx apache   10864 Jul 24  2015 .3bfb23bf-8ff5-4603-aa57-9b23ca498e2c_internet.png.nHmIPk
-????????? ? ?  ?            ?            ? .3bfb3dc5-cb65-435f-8e23-2agcab2c6873_image4993891600240007749.jpg.bV6VTV

यह अस्थायी फ़ाइलों को उत्पन्न करता है जो निर्माण और तेजी से गिराता है जो त्रुटियों का कारण बन जाएगा यदि आप अन्य सरल फ़ाइल प्रबंधन कमांड जैसे rm , mt आदि को कॉल करने का प्रयास करते हैं ।

— मार्टन ताताई
स्रोत

0

बस एक अलग दृष्टिकोण देने के लिए - मेरे पास यह तब था जब मैं एक फ़ाइल (रूबी में) एक सूची निर्देशिका से प्रोग्राम उत्पन्न कर रहा था।

बेशक, फ़ाइल से लाइन अंत में \ n के साथ एक स्ट्रिंग के रूप में आई थी - जो अच्छी दिखती थी और काम करने लगती थी। हालाँकि जैसा कि मैंने निर्देशिकाओं को बनाना शुरू किया, बल्कि यह ठगा हुआ था कि यह प्रत्येक निर्देशिका में से दो का निर्माण करते हुए समाप्त हो गया: /whatiwantedऔर /whatiwanted?।

— ल्यूक पीयर्स
स्रोत

0

मैं कभी-कभी इसे एक क्षणिक त्रुटि के रूप में देखता हूं जब एक एनएफएस सर्वर भारी रूप से ओवरलोड होता है।

ओपी ने RAID के बारे में पूछा, लेकिन कई जवाबों ने एनएफएस का उल्लेख किया, और वास्तव में वह खोज थी जो मुझे यहां ले आई।

— एआरपी
स्रोत