ความเสียหายของระบบไฟล์หลังโพสต์ฉับพลันพลังงานสูญหายบนพาร์ติชัน ext3 ของไดรฟ์ SSD“ พฤติกรรมที่คาดหวัง” หรือไม่


13

บริษัท ของฉันสร้างอุปกรณ์ Debian Linux ที่บู๊ตจากพาร์ติชัน ext3 บนไดรฟ์ SSD ภายใน เนื่องจากอุปกรณ์ดังกล่าวเป็น "กล่องดำ" ในตัวจึงมักจะปิดวิธีที่หยาบคายโดยเพียงตัดไฟเข้าอุปกรณ์ผ่านสวิตช์ภายนอก

โดยปกติจะไม่เป็นไรเนื่องจากการทำเจอร์นัลของ ext3 จะเก็บสิ่งต่าง ๆ ตามลำดับดังนั้นนอกเหนือจากการสูญเสียบางส่วนของไฟล์บันทึกเป็นครั้งคราว

อย่างไรก็ตามเมื่อเร็ว ๆ นี้เราได้เห็นหน่วยจำนวนหนึ่งซึ่งหลังจากฮาร์ดไดรฟ์พลังรอบจำนวนมากพาร์ติชัน ext3 เริ่มพัฒนาปัญหาเชิงโครงสร้างโดยเฉพาะเราเรียกใช้ e2fsck บนพาร์ติชัน ext3 และพบปัญหาเช่นนั้น แสดงในรายการผลลัพธ์ที่ด้านล่างของคำถามนี้ การรัน e2fsck จนกว่าจะหยุดการรายงานข้อผิดพลาด (หรือการฟอร์แมตพาร์ติชันใหม่) จะเป็นการล้างปัญหา

คำถามของฉันคือ ... อะไรคือความหมายของการเห็นปัญหาเช่นนี้ในระบบ ext3 / SSD ที่ต้องเผชิญกับการปิดเครื่องอย่างกะทันหัน / ไม่คาดคิด?

ความรู้สึกของฉันคือว่านี่อาจเป็นสัญญาณของปัญหาซอฟต์แวร์หรือฮาร์ดแวร์ในระบบของเราเนื่องจากความเข้าใจของฉันคือคุณสมบัติการทำเจอร์นัลของ ext3 (เพื่อป้องกันข้อผิดพลาดหรือปัญหาฮาร์ดแวร์) ของ ext3 ควรจะป้องกันข้อผิดพลาดของระบบไฟล์ (หมายเหตุ: ฉันเข้าใจว่าข้อมูลผู้ใช้ไม่ได้ถูกทำเจอร์นัลและไฟล์ผู้ใช้ที่ถูกบันทึก / หายไป / ถูกตัดทอนสามารถเกิดขึ้นได้ฉันกำลังพูดถึงที่นี่โดยเฉพาะเกี่ยวกับข้อผิดพลาดของระบบแฟ้มเมตาดาต้าที่แสดงด้านล่าง)

ในทางกลับกันเพื่อนร่วมงานของฉันบอกว่าสิ่งนี้เป็นที่รู้จัก / พฤติกรรมที่คาดหวังเพราะบางครั้งคอนโทรลเลอร์ SSD สั่งการเขียนคำสั่งซ้ำและอาจทำให้ ext3 เจอร์นัลสับสน โดยเฉพาะอย่างยิ่งเขาเชื่อว่าแม้จะได้รับตามปกติฮาร์ดแวร์ที่ทำงานและซอฟต์แวร์ที่ปราศจากข้อผิดพลาดวารสาร ext3 เพียงทำให้ความเสียหายของระบบไฟล์มีโอกาสน้อยลงเป็นไปไม่ได้ดังนั้นเราจึงไม่แปลกใจที่จะเห็นปัญหาเช่นนี้เป็นครั้งคราว

พวกเราคนไหนถูก

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 จะดีขึ้นหรือยัง
Jeremy Friesner

1
ตัวเลือกทั้งสองจะแก้ไขปัญหานี้ เรายังคงใช้อุปกรณ์ที่มี supercapacitors ใน ZFS และแนะนำให้ใช้แคชของแบตเตอรี่หรือป้องกันแฟลชสำหรับ ext4 ในแอปพลิเคชันเซิร์ฟเวอร์
ewwhite

คำตอบ:


11

คุณผิดทั้งคู่ (อาจจะ?) ... ext3 จัดการปัญหาได้ดีที่สุดเมื่อลบที่เก็บข้อมูลพื้นฐานออกไปทันที

SSD ของคุณอาจมีออนบอร์ดแคชบางประเภท คุณไม่พูดถึงยี่ห้อ / รุ่น SSD ในการใช้งาน แต่เสียงนี้เหมือน SSD ผู้บริโภคระดับเมื่อเทียบกับองค์กรหรืออุตสาหกรรมชั้นรุ่น

ไม่ว่าจะใช้วิธีใดแคชจะช่วยให้สามารถเขียนและยืดอายุการใช้งานของไดรฟ์ได้ หากมีการเขียนระหว่างทางการสูญเสียพลังงานอย่างฉับพลันนั้นเป็นสาเหตุของการทุจริตของคุณ ที่แท้จริงขององค์กรและ SSD อุตสาหกรรมมีsupercapacitorsที่รักษาอำนาจนานพอที่จะย้ายข้อมูลจากแคชกับการจัดเก็บลบเลือนมากในทางเดียวกันแบตเตอรี่สำรองและแฟลชได้รับการสนับสนุนแคชควบคุม RAID ทำงาน

หากไดรฟ์ของคุณไม่มี supercap ธุรกรรมในเที่ยวบินจะหายไปดังนั้นระบบไฟล์จึงเสียหาย ext3 อาจถูกบอกว่าทุกอย่างอยู่ในที่จัดเก็บข้อมูลที่มีเสถียรภาพ แต่นั่นเป็นเพียงฟังก์ชั่นของแคช


ขออภัยสำหรับคุณและทุกคนที่สนับสนุนสิ่งนี้ แต่คุณผิด การจัดการการสูญเสียความคืบหน้าในการเขียนเป็นสิ่งที่เจอร์นัลมีไว้และตราบใดที่ไดรฟ์รายงานอย่างถูกต้องว่ามีแคชการเขียนและปฏิบัติตามคำสั่งเพื่อล้างมันเจอร์นัลจะรับประกันว่าข้อมูลเมตาจะไม่สอดคล้องกัน คุณต้องใช้แคชการจู่โจม supercap หรือแบตเตอรีสำรองเพื่อให้คุณสามารถเปิดใช้งานการเขียนแคชโดยไม่ต้องเปิดใช้งานอุปสรรคซึ่งเสียสละประสิทธิภาพบางอย่างเพื่อรักษาความถูกต้องของข้อมูล
psusi

@psusi SSD ที่ใช้งานอยู่อาจเปิดใช้งานแคชอย่างชัดเจนหรืออาศัยบัฟเฟอร์ภายในโดยไม่คำนึงถึงการตั้งค่า OS_level ข้อมูลในแคชนั้นเป็นสิ่งที่SSD ที่เปิดใช้งาน supercapacitorจะปกป้อง
ewwhite

ข้อมูลในแคชไม่จำเป็นต้องปกป้องหากคุณเปิดใช้งานอุปสรรค 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 อาจโกหกว่าข้อมูลถูกลบทิ้งหรือไม่ คุณต้องการ supercap นั้น
Joel Coel

2

คุณพูดถูกและเพื่อนร่วมงานของคุณผิด หากมีสิ่งผิดปกติเกิดขึ้นในวารสารทำให้แน่ใจได้ว่าคุณไม่เคยมีข้อมูลเมตา fs ที่ไม่สอดคล้องกัน คุณอาจตรวจสอบhdparmเพื่อดูว่าแคชการเขียนของไดรฟ์เปิดใช้งานอยู่หรือไม่ ถ้าเป็นเช่นนั้นและคุณยังไม่ได้เปิดใช้งานอุปสรรค IO (ปิดเป็นค่าเริ่มต้นใน ext3, โดยค่าเริ่มต้นใน ext4) นั่นจะเป็นสาเหตุของปัญหา

ปัญหาและอุปสรรคที่จำเป็นในการบังคับให้แคชการเขียนไดรฟ์ล้างข้อมูลในเวลาที่ถูกต้องเพื่อรักษาความสอดคล้อง แต่ไดรฟ์บางตัวมีพฤติกรรมที่ไม่ดีและรายงานว่าแคชการเขียนของพวกเขาถูกปิดใช้งานเมื่อไม่ได้ใช้งาน สิ่งนี้จะป้องกันไม่ให้วารสารทำหน้าที่ของมัน


-1 เพื่อความเข้าใจในการอ่าน ...
ewwhite

@ ขาวคุณอาจลองอ่านและเขียนคำตอบที่มีประโยชน์แทนการดูถูกเด็ก ๆ
psusi

+1 คำตอบนี้อาจปรับปรุงได้เช่นเดียวกับคำตอบอื่น ๆ ใน QA ใด ๆ แต่อย่างน้อยก็ให้แสงและคำแนะนำบางอย่าง @ downvoters: ปรับปรุงคำตอบของคุณเองหรือแสดงความคิดเห็นเกี่ยวกับกระแสที่เป็นไปได้ แต่การลบคำตอบนี้โดยไม่มีเหตุผลที่เหมาะสมนั้นเป็นเรื่องน่าขยะแขยง!
Alberto
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.