उबंटू मेरी हार्ड ड्राइव को हर बार जांचने के लिए क्यों कहता है?

30

हाल ही में, मैं अपने कंप्यूटर को पुनः आरंभ करने के लिए बाध्य हुआ हूं। जब मैं बूट करता हूं, उबंटू अब त्रुटियों के लिए मेरी हार्ड ड्राइव को स्कैन करना शुरू कर देता है, लेकिन मुझे विश्वास दिलाता है कि अगर मैं 'सी' दबाकर रद्द कर सकता हूं।

उबंटू ऐसा क्यों करता है? यदि यह आवश्यक है, तो यह कुछ ऐसा क्यों है जिसे मैं रद्द कर सकता हूं? यदि यह आवश्यक नहीं है, तो मुझे ऐसा करने के लिए क्यों मजबूर किया जाए? किस आधार पर पुनरारंभ की संख्या तय की गई है?

boot disk-check

— JML
स्रोत

1

क्या आप एक रिबूट के लिए मजबूर कर रहे हैं? उदाहरण के लिए, पॉवर कुंजी दबाए रखें या रीसेट कुंजी दबाएं?

— क्रिस्पर हार्पर

33

एक डिस्क चेक को सिस्टम द्वारा हर 30 रीस्टार्ट के लिए मजबूर किया जाता है। यदि आप डिस्क को छोड़ देते हैं, तो यह अगली बार आपके द्वारा पुनः आरंभ करने (जब तक कि आप मैन्युअल रूप से नहीं निकालते forcecheck) नहीं करेंगे।

आप फ़ाइल forcefsckको /जारी करके अपने आप को मजबूर कर सकते हैं

touch /forcecheck

टर्मिनल से।

जब यह संकेत दिया जाता है, तो हमेशा जांच करना आवश्यक नहीं होता है, लेकिन इसे हर हाल में किया जाना चाहिए। आप इसे रद्द कर सकते हैं यदि यह उस समय आपके लिए सही समय नहीं है और इसे अधिक सुविधाजनक होने पर फाइल सिस्टम को जांचने दें।

आप tune2fsइस व्यवहार को बदलने के लिए भी उपयोग कर सकते हैं ।

sudo tune2fs -c 60 /dev/sdXY

इसे 60 रीस्टार्ट पर सेट करेगा। आप इसे समय अवधि के साथ बदल भी सकते हैं -i:

sudo tune2fs -i 30d /dev/sdXY

30 दिनों के लिए या 1 महीने के लिए 1 मी या 10 सप्ताह के लिए 10 डब्ल्यू।

( /dev/sdXYजैसे विभाजन के लिए डिवाइस नाम से प्रतिस्थापित करें /dev/sda1। आप इस नाम को रनिंग द्वारा प्राप्त कर सकते हैं sudo blkidया ls -lA /dev/disk/by-labelयदि विभाजन लेबल है)

sudo dumpe2fs /dev/sda1

लोड और जानकारी के भार दिखाएगा। इसके भाग में शामिल हैं:

Filesystem created:       Thu Feb 12 09:06:50 2009
Last mount time:          Fri Aug 26 07:19:34 2011
Last write time:          Fri Aug 26 07:19:34 2011
Mount count:              2
Maximum mount count:      25
Last checked:             Fri Aug 12 07:22:16 2011
Check interval:           15552000 (6 months)
Next check after:         Wed Feb  8 06:22:16 2012

— Rinzwind
स्रोत

धन्यवाद @Lekensteyn (इसे स्मृति से लिया था और मेरी स्मृति कभी-कभी खराब लगती है;))

— रिनविंड

3

यहां एक नाइट-पिकर होने के लिए: मुझे लगता है कि यह सच नहीं है कि "चेक सिस्टम में फ़ाइल फोर्सफेक इन /" डालकर मजबूर किया जाता है (आमतौर पर नहीं, फस्क चेक की जांच करता है कि क्या फाइल सिस्टम "गंदा" है या "अधिकतम-गणना" अतीत में है / "अगला चेक") और यह कि "यह हर 30 रीस्टार्ट किया जाता है" (यह भिन्न होता है, उस प्रोग्राम के आधार पर जो आप विभाजन को प्रारूपित करने के लिए उपयोग करते हैं)। दोनों के लिए आउटपुट की जाँच करें dumpe2fs। ubuntugeek.com/…

— व्यवस्थित करें

1

यह nitpicking व्यवस्था नहीं है :-) यह सही है। उसे बदल दिया।

— रिनविविंड wind’११ 33:३३

यह उबंटू के डिफ़ॉल्ट * फाइल सिस्टम के केवल * परिवार पर लागू होता है। एक्सएफएस या जेएफएस नियमित रूप से फाइलसिस्टम चेक नहीं करते हैं

— जनवरी

3

क्या आपको दो बार उल्लेख forcecheckकरना forcefsckचाहिए? (रेफ: askubuntu.com/questions/14740/… )

— idbrii

5

ये रूटीन फाइल सिस्टम चेक हैं, जो हर 30 रिबूट की पहल करते हैं। इसे रद्द करने का विकल्प वहाँ है ताकि आपको किसी महत्वपूर्ण चीज़ से हिरासत में न लिया जाए, हालाँकि, इसे एक बार चलने देने की सिफारिश की जाती है। मैं नहीं जानता कि किस आधार पर रिबूट की संख्या निर्धारित की गई थी, संभवतः, सामान्य ज्ञान। यदि यह बहुत कष्टप्रद है, तो आप 'ट्यून 2 एफए' कमांड का उपयोग करके विभाजन की जांच किए बिना रिबूट की संख्या बढ़ा सकते हैं।

— mikewhatever
स्रोत

माइक: yesterdayऊपर क्लिक करके Lekensteynदेखें कि क्या बदल गया है।

— रिनजविंड

1

उपयोग कर रहे फाइल-सिस्टम पर पूरी तरह से फाइल सिस्टम जांच को अक्षम करना संभव है:

sudo tune2fs -c 0 /dev/sdXY

यह एक अच्छा विचार नहीं हो सकता है। Tune2fs मैनपेज नोट्स:

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

— थॉमस
स्रोत

0

जबकि mikewhatever और Rinzwind ext-filesystems के लिए सही हैं, afaik, यह तब नहीं होता है जब आप reiserfs का उपयोग करना चुनते हैं। मैं समस्याओं के बिना 10 साल से इसका उपयोग कर रहा हूं और इसकी सिफारिश कर सकता हूं। कोई भी अधिक fsck नहीं।

मैं अन्य फाइल सिस्टम के लिए नहीं जानता, जो लिनक्स पर लोकप्रिय है।

— अज्ञात उपयोगकर्ता
स्रोत

4

reiserfsck वास्तव में मरम्मत से परे फाइलसिस्टम को तोड़ने की प्रवृत्ति है। यदि एक reiserfs कभी एक समस्या विकसित करता है, तो वह खेल खत्म हो गया है।

— साइमन रिक्टर

1

क्या आपके साथ ऐसा हुआ, या आपके पास संदर्भ हैं?

— उपयोगकर्ता अज्ञात

तथ्य यह है कि ReiserFS इन चेक का प्रदर्शन नहीं करता है इसकी विश्वसनीयता पर कोई असर नहीं पड़ता है। एक्सट 3 रॉक-सॉलिड है, लेकिन चेक केवल कुछ सेकंड लेते हैं, तो क्यों नहीं?

— मोनिका

मैं ऐसे कई लोगों को जानता हूं जिन्होंने डेटा खो दिया है, और फाइलसिस्टम के डिज़ाइन से यह स्पष्ट है कि क्यों: इसमें कोई मेटाडेटा ब्लॉक नहीं है। हालांकि यह कई मामलों में एक फायदा है (यदि मेटाडेटा ब्लॉक से बाहर निकाला जाता है, तो आप अधिक डेटा नहीं बना सकते हैं, भले ही आपके पास अभी भी मुफ्त डेटा ब्लॉक है), यह किसी भी तरह से एक फाइल सिस्टम को उबारते समय अस्पष्टता पैदा करता है जो किसी भी तरह (हार्डवेयर गलती, बग के लिए कम है परतें) असंगत हो गई हैं।

— साइमन रिक्टर

मैं अभी भी dmesg के अनुसार reiserfs प्रारूप "3.6" का उपयोग कर रहा हूं। हो सकता है कि कोई फर्क पड़े?

— उपयोगकर्ता अज्ञात