रेगुलर लॉगिंग सिस्टम के अलावा, BTRFS में एक है आँकड़े कमांड, जो प्रति ड्राइव (रीड, राइट और करप्शन / चेकसम एरर सहित) त्रुटियों का ट्रैक रखता है:
# btrfs device stats /
[/dev/mapper/luks-123].write_io_errs 0
[/dev/mapper/luks-123].read_io_errs 0
[/dev/mapper/luks-123].flush_io_errs 0
[/dev/mapper/luks-123].corruption_errs 0
[/dev/mapper/luks-123].generation_errs 0
तो आप एक साधारण रूट क्रॉस्टैब बना सकते हैं:
MAILTO=admin@myserver.com
@hourly /sbin/btrfs device stats /data | grep -vE ' 0$'
यह हर घंटे सकारात्मक त्रुटि की जाँच करेगा और आपको एक ईमेल भेजेगा। जाहिर है, आप इस तरह के परिदृश्य का परीक्षण करेंगे (उदाहरण के लिए भ्रष्टाचार के कारण या grep को हटाकर) यह सत्यापित करने के लिए कि ईमेल अधिसूचना काम करती है।
इसके अलावा, BTRFS (जैसे कि चेकसमिंग) जैसे उन्नत फाइल सिस्टम के साथ, यह अक्सर एक खराब ड्राइव के कारण होने वाले मूक भ्रष्टाचार का पता लगाने के लिए हर दो हफ्ते में एक स्क्रब शेड्यूल करने की सिफारिश की जाती है।
@monthly /sbin/btrfs scrub start -Bq /data
-B विकल्प स्क्रब को अग्रभूमि में रखेगा, ताकि आप देखेंगे कि ईमेल क्रोन में परिणाम आपको भेजता है। अन्यथा, यह पृष्ठभूमि में चलेगा और आपको मैन्युअल रूप से परिणामों की जांच करना याद रखना होगा क्योंकि वे ईमेल में नहीं होंगे।
अद्यतन करें : माइकल Kjörling, धन्यवाद द्वारा सुझाए गए बेहतर grep।
अपडेट २ :
नियमित रूप से पढ़े गए कार्यों के लिए स्क्रबिंग पर अतिरिक्त नोट (यह केवल BTRFS पर लागू नहीं होता है):
जैसा कि आयान द्वारा बताया गया है, कुछ मामलों में एक दिन से भी अधिक सरणी (और अन्य कारकों) के आकार और प्रकार के आधार पर एक स्क्रब में कई घंटे लग सकते हैं। और यह एक सक्रिय स्कैन है, यह भविष्य की त्रुटियों का पता नहीं लगाएगा - स्क्रब का लक्ष्य उस समय आपके ड्राइव पर त्रुटियों को ढूंढना और ठीक करना है। लेकिन अन्य RAID प्रणालियों के साथ, यह समय-समय पर स्क्रब शेड्यूल करने के लिए अनुशंसित है। यह सच है कि एक विशिष्ट i / o ऑपरेशन, एक फ़ाइल को पढ़ने की तरह, यह जांचता है कि क्या पढ़ा गया डेटा वास्तव में सही है। लेकिन एक साधारण दर्पण पर विचार करें - यदि फ़ाइल की पहली प्रति क्षतिग्रस्त हो जाती है, हो सकता है कि एक ड्राइव जो मरने वाला हो, लेकिन दूसरी प्रति, जो सही है, वास्तव में BTRFS द्वारा पढ़ी जाती है, तो BTRFS को पता नहीं चलेगा कि भ्रष्टाचार है एक ड्राइव पर। यह केवल इसलिए है क्योंकि अनुरोधित डेटा प्राप्त हुआ है, यह इस फाइल के लिए चेकसम BTRFS द्वारा संग्रहित किया गया है, इसलिए दूसरी प्रतिलिपि को पढ़ने के लिए BTRFS की आवश्यकता नहीं है। इसका मतलब यह है कि भले ही आप विशेष रूप से एक फ़ाइल को पढ़ते हैं जिसे आप जानते हैं कि एक ड्राइव पर भ्रष्ट है, इस बात की कोई गारंटी नहीं है कि इस रीड ऑपरेशन से भ्रष्टाचार का पता लगाया जाएगा।
अब, मान लेते हैं कि BTRFS केवल अच्छी ड्राइव से पढ़ता है, कोई स्क्रब नहीं चलाया जाता है जो खराब ड्राइव पर नुकसान का पता लगाता है, और फिर अच्छी ड्राइव खराब भी हो जाती है - परिणाम डेटा हानि (कम से कम BTRFS को पता होगा) कौन सी फाइलें अभी भी सही हैं और फिर भी आप उन्हें पढ़ने की अनुमति देंगे)। बेशक, यह एक सरल उदाहरण है; वास्तव में, BTRFS हमेशा एक ड्राइव से नहीं पढ़ेगा और दूसरे की अनदेखी करेगा।
लेकिन मुद्दा यह है कि आवधिक स्क्रब महत्वपूर्ण हैं क्योंकि वे त्रुटि (और ठीक) पाएंगे जो नियमित रूप से पढ़ने के संचालन का पता नहीं लगाएगा।
दोषपूर्ण ड्राइव : चूंकि यह प्रश्न काफी लोकप्रिय है, मैं यह बताना चाहता हूं कि यह "मॉनिटरिंग सॉल्यूशन" संभवतः खराब ड्राइव के साथ समस्याओं का पता लगाने के लिए है (उदाहरण के लिए, मरने वाली ड्राइव त्रुटियों का कारण है, लेकिन अभी भी सुलभ है)।
दूसरी ओर, अगर कोई ड्राइव अचानक चला गया है (मरने या उत्पादन त्रुटियों के बजाय पूरी तरह से मृत हो गया है), यह एक दोषपूर्ण ड्राइव होगा (ZFS इस तरह के ड्राइव को FAULTED के रूप में चिह्नित करेगा)। दुर्भाग्य से, BTRFS को यह महसूस नहीं हो सकता है कि फाइलसिस्टम माउंट होने के दौरान एक ड्राइव चला गया है, जैसा कि इस मेलिंग सूची में 09/2015 से दर्ज किया गया है (यह संभव है कि यह पैच हो गया है):
अंतर यह है कि हमारे पास माउंट पर मौजूद डिवाइस का पता लगाने के लिए कोड नहीं है, हमारे पास माउंटेड फाइल सिस्टम पर इसे छोड़ने का पता लगाने के लिए कोड (अभी तक) नहीं है। किसी उपकरण के गायब होने का उचित पता लगाना एक प्राथमिकता के रूप में क्यों नहीं दिखाई देता है, मुझे पता नहीं है, लेकिन यह माउंट व्यवहार से एक अलग मुद्दा है।
https://www.mail-archive.com/linux-btrfs@vger.kernel.org/msg46598.html
उस समय तक dmesg में बहुत सारे त्रुटि संदेश होंगे, इसलिए dmesg को विश्वसनीय नहीं माना जा सकता है।
BTRFS का उपयोग करने वाले सर्वर के लिए, यह एक कस्टम चेक (क्रोन जॉब) करने का विचार हो सकता है जो RAID सरणी में कम से कम एक ड्राइव में अलर्ट भेजता है, अर्थात, अब सुलभ नहीं है ...