Czy uszkodzenie systemu plików po nagłej utracie zasilania na partycji ext3 dysku SSD jest „oczekiwanym zachowaniem”?

Moja firma produkuje wbudowane urządzenie Debian Linux, które uruchamia się z partycji ext3 na wewnętrzny dysk SSD. Ponieważ urządzenie jest osadzoną „czarną skrzynką”, zwykle jest ono zamykane niegrzecznie, po prostu odcinając zasilanie urządzenia za pomocą zewnętrznego przełącznika.

Zwykle jest to w porządku, ponieważ dziennikowanie ext3 utrzymuje porządek, więc poza sporadyczną utratą części pliku dziennika, wszystko nadal się ładnie ładuje.

Jednak ostatnio widzieliśmy wiele jednostek, w których po wielu cyklach zasilania twardego partycja ext3 zaczyna rozwijać problemy strukturalne - w szczególności uruchamiamy e2fsck na partycji ext3 i znajduje wiele problemów takich jak te pokazane na liście wyników na dole tego pytania. Uruchamianie e2fsck, aż przestanie zgłaszać błędy (lub ponownie formatować partycję), usuwa problemy.

Moje pytanie brzmi ... jakie są konsekwencje zobaczenia takich problemów w systemie ext3 / SSD, który został poddany wielu nagłym / nieoczekiwanym wyłączeniom?

Mam wrażenie, że może to oznaczać problem z oprogramowaniem lub sprzętem w naszym systemie, ponieważ rozumiem, że (poza błędem lub problemem sprzętowym) funkcja rejestrowania w ext3 ma zapobiegać tego rodzaju błędom integralności systemu plików. (Uwaga: Rozumiem, że dane użytkownika nie są rejestrowane w dzienniku, więc mogą się zdarzyć mung / brakujące / obcięte pliki użytkownika; Mówię tu konkretnie o błędach metadanych systemu plików, takich jak te pokazane poniżej)

Z drugiej strony mój współpracownik mówi, że jest to znane / oczekiwane zachowanie, ponieważ kontrolery SSD czasami zmieniają kolejność poleceń zapisu i mogą powodować dezorientację dziennika ext3. W szczególności uważa, że ​​nawet biorąc pod uwagę normalnie działający sprzęt i oprogramowanie wolne od błędów, dziennik ext3 sprawia, że ​​uszkodzenie systemu plików jest mniej prawdopodobne, a nie niemożliwe, dlatego nie powinniśmy być zaskoczeni, widząc takie problemy od czasu do czasu.

Który z nas ma rację?

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

Oboje jesteście w błędzie (może?) ... ext3 radzi sobie najlepiej, jak może, usuwając swoje podstawowe miejsce tak gwałtownie.

Twój dysk SSD prawdopodobnie ma wbudowaną pamięć podręczną. Nie wspominasz o użytej marce / modelu SSD, ale brzmi to jak dysk SSD na poziomie konsumenta w porównaniu z modelem klasy korporacyjnej lub przemysłowej .

Tak czy inaczej, pamięć podręczna służy do łączenia zapisów i przedłużania żywotności dysku. Jeśli w trakcie tranzytu pojawiają się zapisy, nagła utrata mocy jest z pewnością źródłem zepsucia. Prawdziwe korporacyjne i przemysłowe dyski SSD mają superkondensatory, które utrzymują moc wystarczająco długo, aby przenosić dane z pamięci podręcznej do trwałej pamięci, podobnie jak działają pamięci podręczne kontrolerów RAID z podtrzymaniem bateryjnym i flash .

Jeśli twój dysk nie ma superkapsy, transakcje w locie są tracone, co powoduje uszkodzenie systemu plików. ext3 prawdopodobnie mówi się, że wszystko jest w stabilnej pamięci, ale to tylko funkcja pamięci podręcznej.

Masz rację, a twój współpracownik się myli. Z wyjątkiem sytuacji, gdy coś pójdzie nie tak, dziennik gwarantuje, że nigdy nie będziesz mieć niespójnych metadanych fs. Możesz sprawdzić za pomocą, hdparmaby sprawdzić, czy pamięć podręczna zapisu napędu jest włączona. Jeśli tak jest, a bariery we / wy nie zostały włączone (domyślnie wyłączone w ext3, domyślnie włączone w ext4), to byłaby przyczyną problemu.

Bariery są potrzebne, aby zmusić pamięć podręczną zapisu napędu do opróżnienia we właściwym czasie, aby zachować spójność, ale niektóre dyski są źle zachowane i albo zgłaszają, że ich pamięć podręczna zapisu jest wyłączona, gdy tak nie jest, lub dyskretnie ignorują polecenia opróżniania. Zapobiega to wykonywaniu zadania przez dziennik.