क्या एसएसडी ड्राइव के एक्स 3 विभाजन "अपेक्षित व्यवहार" पर अचानक पावर-लॉस फाइल सिस्टम भ्रष्टाचार है?


13

मेरी कंपनी एक एम्बेडेड डेबियन लिनक्स डिवाइस बनाती है जो एक आंतरिक एसएसडी ड्राइव पर एक एक्स 3 विभाजन से बूट होती है। क्योंकि डिवाइस एक एम्बेडेड "ब्लैक बॉक्स" है, यह आमतौर पर एक बाहरी स्विच के माध्यम से डिवाइस को बिजली काटकर, कठोर तरीके से बंद कर दिया जाता है।

यह सामान्य रूप से ठीक है, क्योंकि ext3 की पत्रिकाओं को क्रम में रखता है, इसलिए लॉग फ़ाइल के हिस्से के सामयिक नुकसान के अलावा, चीजें ठीक-ठाक रहती हैं।

हालाँकि, हमने हाल ही में कई इकाइयाँ देखी हैं, जहाँ कई हार्ड-पॉवर-साइकल के बाद ext3 पार्टीशन से स्ट्रक्चरल इश्यूज विकसित होने लगते हैं - विशेष रूप से, हम e2fsck को ext3 पार्टीशन पर चलाते हैं और यह उन जैसे कई इश्यू को ढूंढता है इस प्रश्न के नीचे आउटपुट लिस्टिंग में दिखाया गया है। जब तक यह रिपोर्टिंग त्रुटियों (या विभाजन को पुन: स्वरूपित करना) को बंद नहीं करता तब तक e2fsck चल रहा है।

मेरा सवाल यह है कि एक ext3 / SSD प्रणाली पर इस तरह की समस्याओं को देखने के निहितार्थ क्या हैं जो अचानक / अप्रत्याशित शटडाउन के बहुत सारे के अधीन हैं?

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

दूसरी ओर, मेरे सह-कार्यकर्ता का कहना है कि यह ज्ञात / अपेक्षित व्यवहार है क्योंकि SSD नियंत्रक कभी-कभी आदेश लिखते हैं और इससे ext3 पत्रिका भ्रमित हो सकती है। विशेष रूप से, उनका मानना ​​है कि सामान्य रूप से काम करने वाले हार्डवेयर और बग-फ्री सॉफ्टवेयर भी दिए गए हैं, एक्स 3 जर्नल केवल फाइल सिस्टम भ्रष्टाचार को कम करता है, असंभव नहीं है, इसलिए हमें समय-समय पर इस तरह की समस्याओं को देखकर आश्चर्यचकित नहीं होना चाहिए।

हममें से कौन सही है?

Embedded-PC-failsafe:~# ls
Embedded-PC-failsafe:~# umount /mnt/unionfs
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Invalid inode number for '.' in directory inode 46948.
Fix<y>? yes

Directory inode 46948, block 0, offset 12: directory corrupted
Salvage<y>? yes

Entry 'status_2012-11-26_14h13m41.csv' in /var/log/status_logs (46956) has deleted/unused inode 47075.  Clear<y>? yes
Entry 'status_2012-11-26_10h42m58.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47076.  Clear<y>? yes
Entry 'status_2012-11-26_11h29m41.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47080.  Clear<y>? yes
Entry 'status_2012-11-26_11h42m13.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47081.  Clear<y>? yes
Entry 'status_2012-11-26_12h07m17.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47083.  Clear<y>? yes
Entry 'status_2012-11-26_12h14m53.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47085.  Clear<y>? yes
Entry 'status_2012-11-26_15h06m49.csv' in /var/log/status_logs (46956) has deleted/unused inode 47088.  Clear<y>? yes
Entry 'status_2012-11-20_14h50m09.csv' in /var/log/status_logs (46956) has deleted/unused inode 47073.  Clear<y>? yes
Entry 'status_2012-11-20_14h55m32.csv' in /var/log/status_logs (46956) has deleted/unused inode 47074.  Clear<y>? yes
Entry 'status_2012-11-26_11h04m36.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47078.  Clear<y>? yes
Entry 'status_2012-11-26_11h54m45.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47082.  Clear<y>? yes
Entry 'status_2012-11-26_12h12m20.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47084.  Clear<y>? yes
Entry 'status_2012-11-26_12h33m52.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47086.  Clear<y>? yes
Entry 'status_2012-11-26_10h51m59.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47077.  Clear<y>? yes
Entry 'status_2012-11-26_11h17m09.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47079.  Clear<y>? yes
Entry 'status_2012-11-26_12h54m11.csv.gz' in /var/log/status_logs (46956) has deleted/unused inode 47087.  Clear<y>? yes

Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Couldn't fix parent of inode 46948: Couldn't find parent directory entry

Pass 4: Checking reference counts
Unattached inode 46945
Connect to /lost+found<y>? yes

Inode 46945 ref count is 2, should be 1.  Fix<y>? yes
Inode 46953 ref count is 5, should be 4.  Fix<y>? yes

Pass 5: Checking group summary information
Block bitmap differences:  -(208264--208266) -(210062--210068) -(211343--211491) -(213241--213250) -(213344--213393) -213397 -(213457--213463) -(213516--213521) -(213628--213655) -(213683--213688) -(213709--213728) -(215265--215300) -(215346--215365) -(221541--221551) -(221696--221704) -227517
Fix<y>? yes

Free blocks count wrong for group #6 (17247, counted=17611).
Fix<y>? yes

Free blocks count wrong (161691, counted=162055).
Fix<y>? yes

Inode bitmap differences:  +(47089--47090) +47093 +47095 +(47097--47099) +(47101--47104) -(47219--47220) -47222 -47224 -47228 -47231 -(47347--47348) -47350 -47352 -47356 -47359 -(47457--47488) -47985 -47996 -(47999--48000) -48017 -(48027--48028) -(48030--48032) -48049 -(48059--48060) -(48062--48064) -48081 -(48091--48092) -(48094--48096)
Fix<y>? yes

Free inodes count wrong for group #6 (7608, counted=7624).
Fix<y>? yes

Free inodes count wrong (61919, counted=61935).
Fix<y>? yes


embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****

embeddedrootwrite: ********** WARNING: Filesystem still has errors **********

embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks

Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite contains a file system with errors, check forced.
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Directory entry for '.' in ... (46948) is big.
Split<y>? yes

Missing '..' in directory inode 46948.
Fix<y>? yes

Setting filetype for entry '..' in ... (46948) to 2.
Pass 3: Checking directory connectivity
'..' in /etc/network/run (46948) is <The NULL inode> (0), should be /etc/network (46953).
Fix<y>? yes

Pass 4: Checking reference counts
Inode 2 ref count is 12, should be 13.  Fix<y>? yes

Pass 5: Checking group summary information

embeddedrootwrite: ***** FILE SYSTEM WAS MODIFIED *****
embeddedrootwrite: 657/62592 files (24.4% non-contiguous), 87882/249937 blocks
Embedded-PC-failsafe:~# 
Embedded-PC-failsafe:~# e2fsck /dev/sda3
e2fsck 1.41.3 (12-Oct-2008)
embeddedrootwrite: clean, 657/62592 files, 87882/249937 blocks

क्या आप सभी ने ext4 या ZFS में बदलने के बारे में सोचा है?
mdpc

मैंने ext4 में बदलने के बारे में सोचा है, कम से कम ... जो इस मुद्दे को हल करने में मदद करेगा? क्या ZFS अभी भी बेहतर होगा?
जेरेमी फ्रेज़र

1
न तो विकल्प इसे ठीक करेगा। हम अभी भी ZFS में सुपरकैपेसिटर वाले उपकरणों का उपयोग करते हैं, और सर्वर अनुप्रयोगों में ext4 के लिए बैटरी या फ्लैश-संरक्षित कैश की सिफारिश की जाती है।
ewwhite

जवाबों:


11

आप दोनों गलत हैं (हो सकता है?) ... ext3 सबसे अच्छा मुकाबला कर रहा है, इसके अंतर्निहित भंडारण को अचानक से हटा दिया जा सकता है।

आपके SSD में संभवतः कुछ प्रकार के ऑनबोर्ड कैश हैं। आप उपयोग में एसएसडी के मेक / मॉडल का उल्लेख नहीं करते हैं, लेकिन यह एक उपभोक्ता-स्तर एसएसडी बनाम एक उद्यम या औद्योगिक-ग्रेड मॉडल की तरह लगता है

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

यदि आपके ड्राइव में सुपरकैप नहीं है, तो इन-फ्लाइट लेनदेन खो रहा है, इसलिए फाइल सिस्टम में भ्रष्टाचार है। ext3 शायद बताया जा रहा है कि सब कुछ स्थिर भंडारण पर है, लेकिन यह सिर्फ कैश का एक कार्य है।


आपको और सभी लोगों को क्षमा करें जिन्होंने इसे उकसाया, लेकिन आप सिर्फ गलत हैं। प्रगति लिखने के नुकसान को संभालना वास्तव में वही है जो पत्रिका के लिए है, और जब तक ड्राइव सही ढंग से रिपोर्ट करता है कि क्या उसके पास राइट कैश है और इसे फ्लश करने के लिए आदेशों का पालन करता है, तो जर्नल गारंटी देता है कि मेटाडेटा असंगत नहीं होगा। आपको केवल सुपरकैप या बैटरी समर्थित रेड कैश की आवश्यकता है ताकि आप बाधाओं को सक्षम किए बिना कैश को लिखने में सक्षम कर सकें, जो डेटा शुद्धता बनाए रखने के लिए कुछ प्रदर्शन का बलिदान करता है।
psusi

@psusi उपयोग में SSD में संभवतः OS_level सेटिंग की परवाह किए बिना कैश को स्पष्ट रूप से सक्षम या एक आंतरिक बफर पर निर्भर करता है। उस कैश में डेटा वह है जो एक सुपरकैपेसिटर-सक्षम एसएसडी की रक्षा करेगा।
19

यदि आप IO अवरोधों को सक्षम करते हैं, तो कैश में डेटा की सुरक्षा की आवश्यकता नहीं है। अधिकांश उपभोक्ता प्रकार डिफ़ॉल्ट रूप से राइट कैशिंग अक्षम के साथ जहाज चलाते हैं और यदि आप चाहते हैं तो आपको इसे सक्षम करना होगा, क्योंकि यह भ्रष्टाचार के मुद्दों का कारण बनता है अगर ओएस सावधान नहीं है।
Psusi

2
@pusi पुराना अब, लेकिन आप as long as the drive correctly reports whether it has a write cache and obeys commands to flush it, the journal guarantees that the metadata will not be inconsistent.इसका उल्लेख करते हैं: यह बात है: भंडारण नियंत्रकों के कारण जो पुराने डिस्क को मान लेते हैं, SSD कभी-कभी इस बारे में झूठ बोलेंगे कि क्या डेटा फ़्लश है। आपको उस सुपरकैप की जरूरत है।
जोएल कोएल

2

आप सही हैं और आपका सहकर्मी गलत है। कुछ गलत होने पर पत्रिका को यह सुनिश्चित करना चाहिए कि आपके पास असंगत fs मेटाडेटा कभी नहीं है। आप यह hdparmदेख सकते हैं कि ड्राइव का राइट कैश सक्षम है या नहीं। यदि यह है, और आपने IO बाधाओं को सक्षम नहीं किया है (ext3 पर डिफ़ॉल्ट रूप से, ext4 में डिफ़ॉल्ट रूप से), तो यह समस्या का कारण होगा।

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


-1 पढ़ने-समझने के लिए ...
ewwhite

@ वास्तव में, शायद आपको पढ़ने की कोशिश करनी चाहिए, और वास्तव में इस बचकाना अपमान के बजाय एक उपयोगी प्रतिक्रिया लिखना चाहिए।
Psusi

+1 यह उत्तर संभवतः बेहतर हो सकता है, क्योंकि किसी भी प्रश्नोत्तर में कोई अन्य उत्तर। लेकिन कम से कम कुछ प्रकाश और संकेत प्रदान करता है। @downvoters: अपने उत्तर में सुधार करें, या संभावित प्रवाह पर टिप्पणी करें, लेकिन उचित औचित्य के बिना इस उत्तर को अस्वीकार करना सिर्फ घृणित है!
अल्बर्टो
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.