मैंने देखा कि XFS सिस्टम बूट पर एक fsck को लागू नहीं करता है और उस जर्नलिंग फ़ाइल-सिस्टम में दिए गए कारणों में से एक यह सुनिश्चित करने में मदद करता है कि फ़ाइल-सिस्टम एक अशुद्ध शटडाउन के बाद एक सुसंगत स्थिति में है; अगले माउंट पर (जैसे रिबूट के बाद) पत्रिका फिर से प्रकाशित की जाती है।
क्या अशुद्ध शटडाउन के बाद भी fsck की आवश्यकता है और क्यों?
जवाबों:
मैं इसका जवाब "पत्रिकाओं के फाइल सिस्टम" के सामान्य संदर्भ में दे रहा हूं।
मुझे लगता है कि अगर आपने कई बार "अशुद्ध शटडाउन" ( पावर कॉर्ड या किसी चीज को खींचकर ) किया था, तो आप जल्द ही या बाद में एक फाइलसिस्टम राज्य में पहुंच जाएंगे, जिसके लिए fsckया fsck के नैतिक समकक्ष की आवश्यकता होगी xfs_repair। ext4अधिकांश भाग के लिए अपने लैपटॉप पर fileystsm बस हर रिबूट पर पत्रिका रिप्ले, स्वच्छ शटडाउन शामिल है, लेकिन हर एक समय में एक बार, यह एक पूर्ण पर करता है fsck।
लेकिन खुद से पूछें कि "पत्रिका को फिर से पढ़ना" क्या पूरा करता है। एक पत्रिका को फिर से लिखना यह सुनिश्चित करता है कि बाकी फाइल सिस्टम के डिस्कब्लॉक उस ऑर्डर से मेल खाते हैं जो जर्नल प्रविष्टियों की मांग करता है। एक छोटी राशि fsckया एक पूर्ण पर के कुछ हिस्सों के लिए एक पत्रिका की मात्रा को फिर से पढ़ना fsck।
मुझे लगता है कि हाथ की कुछ मौखिक निंद्रा चल रही है: एक पत्रिका को फिर से प्रकाशित करना पारंपरिक कार्यों का हिस्सा fsckहै, और xfs_repairवास्तव में उसी तरह का कार्यक्रम है e2fs.fsck(या किसी अन्य फाइलसिस्टम का fsck)। एक्सएफएस लोगों को बस विश्वास था या उनके अनुभव ने उन्हें xfs_repairहर बूट पर नहीं चलने के लिए प्रेरित किया , बस जर्नल को फिर से खेलना।
fsck'पांडित्य' नहीं है। मैंने एक ext3 LVMविभाजन को रूपांतरित किया ext4और 'ext4_mb_generate_buddy' त्रुटियां प्राप्त करना शुरू कर दिया, जैसा कि मुझे समझ में आता है, ext4कोड में एक बग के लिए जो डिस्क पर एक बेमेल का कारण बनता है और परिवर्तित LVM के विभाजन के दौरान बिटमैप की मेमोरी प्रतियां। जहां तक मैं बता सकता हूं fsck, कोई भ्रष्टाचार नहीं हुआ। समाधान या तो UNINIT_BGविकल्प को बंद करना था या डेटा को स्थानांतरित करना था और विभाजन को फिर से संगठित करना था ext4; मैंने बाद वाला कोर्स लिया। लेकिन मुझे अभी भी लगता है कि कुछ मिनट इंतजार करने के लिए fsckडेटा नहीं खोना है!
यह सुनिश्चित करने में मदद करें कि अशुद्ध शटडाउन के बाद फाइल-सिस्टम एक सुसंगत स्थिति में है
ध्यान देने वाली पहली बात यह है कि एक्सएफएस, रीज़र और एक्सट के अधिकांश कॉन्फ़िगरेशन केवल मेटा-डेटा जर्नलिंग को लागू करते हैं, जो कि फस्क से बचने के बारे में है। पत्रिका को हमेशा स्टार्ट अप पर रिप्ले नहीं किया जाता है - अगर यह अधूरा है तो इसे छोड़ दिया जा सकता है।
ऐसे सिस्टम हैं जो पूर्ण डेटा जर्नलिंग का समर्थन करते हैं - लेकिन वास्तव में आश्वासन के स्तर पर ये सिर्फ मेटा-डेटा जर्नलिंग दे रहे हैं वास्तविक दुनिया के परिदृश्यों में बहुत कम है।
तो एक 'असंगत स्थिति', और fsck द्वारा तय की गई समस्याएं, मेटा-डेटा और स्वयं फ़ाइलों के बीच बेमेल हैं। इससे बचने के लिए, OS जर्नल में प्रस्तावित मेटा डेटा परिवर्तनों को लिखता है, फिर डिस्क पर वास्तविक डेटा लिखता है, फिर मेटा डेटा परिवर्तनों को लागू करता है जिन्हें डिस्क में जर्नल में दोहराया जाता है। इसके साथ एकमात्र पकड़ यह है कि डिस्क नियंत्रक बफर करेगा और संभावित रूप से अनुरोधों को फिर से व्यवस्थित करेगा। इससे बचने के लिए, अधिकांश जर्नलिंग फाइलिंग सिस्टम बाधाओं को लागू करते हैं: वे प्रत्येक ऑपरेशन को अलग करते हैं और डिस्क को यह स्वीकार करने के लिए प्रतीक्षा करते हैं कि उसने ऑपरेशन पूरा कर लिया है। लेकिन कई आधुनिक डिस्क वास्तव में डेटा के प्रतिबद्ध होने से पहले लिखने के पूरा होने को स्वीकार करते हैं। इसलिए, चीजें गड़बड़ हो सकती हैं।
क्या अशुद्ध शटडाउन के बाद भी एक fsck की आवश्यकता है और क्यों
अधिकांश फाइलसिस्टम माउंट गिनती बनाए रखते हैं - एक बार जब यह गिनती पूरी हो जाती है, तो डिस्क को माउंट करने के अगले प्रयास में एक पूर्ण fsck चालू हो जाएगा। इसका कारण यह है कि डिस्क डेटा दूषित होने पर भी स्पष्ट रूप से लिखा जा सकता है, यहां तक कि सॉफ़्टवेयर में बग के बिना भी। ऊपर सोसुइ की टिप्पणी गलत है।
hdparm -W) को सक्षम नहीं करते हैं , तो डिस्क तब तक लिखने के अनुरोध को पूरा नहीं करता है जब तक कि यह माध्यम पर न हो। आपको क्यों लगता है कि विकल्प मौजूद है? जब कई अनुरोध जारी किए जाते हैं तो अवरोध पुन: व्यवस्थित होने से रोकते हैं। बाधाओं के बिना, एफएस केवल अधिक अनुरोध जारी नहीं करता है जब तक कि पिछले वाले पूरे नहीं होते हैं, इस प्रकार बाधाओं के बिना ऑर्डर बनाए रखना ... बशर्ते कि डिस्क राइट कैश सक्षम नहीं है। बाधाओं का उद्देश्य आपको क्रैश पर एफएस को भ्रष्ट किए बिना, लेखन कैश को सक्षम करने की अनुमति देना है।
sync। मुझे दोबारा प्रयास करने दें। बिना किसी बाधा के डिस्क पर लिखने की प्रक्रिया जर्नल को लिखना है sync, इस प्रकार किसी भी लिखने के कैश को फ्लश करना, फिर वास्तविक डेटा लिखना। यह सुनिश्चित करता है कि जर्नल को क्रैश के बाद एफएस को पुनर्प्राप्त करने के लिए हमेशा उपयोग किया जा सकता है, लेकिन चीजों को धीमा कर देता है और आधा लेखन कैश के उद्देश्य को हरा देता है। इस प्रकार बाधाओं को एक बेहतर प्रतिस्थापन के रूप में जोड़ा गया sync, और उचित डिस्क समर्थन के साथ, वे सुरक्षित रूप से उस प्रदर्शन को पुनः प्राप्त कर सकते हैं जो सिंकिंग दूर ले जाती है।
केवल अशुद्ध शटडाउन के कारण जर्नलिंग फाइलसिस्टम को fsck करने की आवश्यकता नहीं है।
मेटाडेटा जर्नलिंग के रनटाइम परफॉर्मेंस पेनल्टी को समाप्त करने का पूरा कारण यह सुनिश्चित करना है कि यदि फाइल सिस्टम को साफ तौर पर अनमाउंट नहीं किया गया था, तो अगले माउंट पर स्वचालित रूप से मेटाडेटा लॉग को फिर से फाइल करके फाइल सिस्टम को 100% सुसंगत बनाया जा सकता है।
fsck की एकमात्र भूमिका मेटाडेटा स्थिरता सुनिश्चित करने के लिए है, इसलिए केवल फ़ाइल सिस्टम ठीक से अनमाउंट नहीं होने के कारण fsck को चलाना बेमानी है।
एक जर्नलिंग फाइलसिस्टम अन्य कारणों से दूषित हो सकता है, हालांकि - हार्डवेयर विफलता, ड्राइवर बग, व्यवस्थापक त्रुटियां, आदि - इसलिए fsck टूल निश्चित रूप से आवश्यक हैं। अशुद्ध शटडाउन के कारण उन्हें पूरी तरह से आह्वान करने का कोई कारण नहीं है।