Hat das Dateisystem nach einem plötzlichen Stromausfall auf der ext3-Partition eines SSD-Laufwerks das erwartete Verhalten?

Mein Unternehmen stellt ein eingebettetes Debian Linux-Gerät her, das von einer ext3-Partition auf einem internen SSD-Laufwerk gestartet wird. Da das Gerät eine eingebettete "Black Box" ist, wird es normalerweise auf unhöfliche Weise heruntergefahren, indem einfach die Stromversorgung des Geräts über einen externen Schalter unterbrochen wird.

Dies ist normalerweise in Ordnung, da das Journaling von ext3 die Dinge in Ordnung hält. Abgesehen vom gelegentlichen Verlust eines Teils einer Protokolldatei, tuckern die Dinge gut mit.

Wir haben jedoch kürzlich eine Reihe von Einheiten gesehen, in denen die ext3-Partition nach einer Reihe von Hard-Power-Cycles beginnt, strukturelle Probleme zu entwickeln. Insbesondere führen wir e2fsck auf der ext3-Partition aus und finden eine Reihe solcher Probleme wird in der Liste der Ausgaben am Ende dieser Frage angezeigt. Wenn Sie e2fsck so lange ausführen, bis keine Fehler mehr gemeldet werden (oder die Partition neu formatiert wird), werden die Probleme behoben.

Meine Frage ist ... was bedeutet es, solche Probleme auf einem ext3 / SSD-System zu sehen, das vielen plötzlichen / unerwarteten Abschaltungen ausgesetzt war?

Meines Erachtens könnte dies ein Anzeichen für ein Software- oder Hardwareproblem in unserem System sein, da meines Erachtens die Journalling-Funktion von ext3 (abgesehen von Fehlern oder Hardwareproblemen) diese Art von Fehlern bei der Integrität des Dateisystems verhindern soll. (Hinweis: Ich verstehe, dass Benutzerdaten nicht erfasst werden und daher mungierte / fehlende / abgeschnittene Benutzerdateien auftreten können. Ich spreche hier speziell über Dateisystem-Metadaten-Fehler wie die unten gezeigten.)

Mein Kollege sagt andererseits, dass dies ein bekanntes / erwartetes Verhalten ist, da SSD-Controller manchmal Schreibbefehle neu anordnen und dies zu Verwirrung im ext3-Journal führen kann. Insbesondere glaubt er, dass das ext3-Journal selbst bei normal funktionierender Hardware und fehlerfreier Software die Wahrscheinlichkeit einer Beschädigung des Dateisystems verringert und nicht unmöglich macht. Wir sollten uns daher nicht wundern, wenn wir von Zeit zu Zeit solche Probleme bemerken.

Welcher von uns hat Recht?

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

— Jeremy Friesner
quelle

Haben Sie alle darüber nachgedacht, auf ext4 oder ZFS umzusteigen?

— mdpc

Ich habe darüber nachgedacht, auf ext4 umzusteigen. Würde das helfen, dieses Problem zu beheben? Wäre ZFS noch besser?

— Jeremy Friesner

Keine der beiden Optionen würde dies beheben. In ZFS werden weiterhin Geräte mit Superkondensatoren verwendet. In Serveranwendungen wird für ext4 ein batterie- oder flashgeschützter Cache empfohlen.

— ewwhite

Antworten:

Sie sind beide falsch (vielleicht?) ... ext3 schafft es so gut es geht, wenn der zugrunde liegende Speicher so plötzlich entfernt wird.

Ihre SSD verfügt wahrscheinlich über einen Onboard-Cache. Sie erwähnen nicht die Marke / das Modell der verwendeten SSD, aber dies klingt wie eine SSD auf Consumer-Ebene im Vergleich zu einem Modell für Unternehmen oder für die Industrie .

In beiden Fällen wird der Cache verwendet, um Schreibvorgänge zusammenzuführen und die Lebensdauer des Laufwerks zu verlängern. Wenn Schreibvorgänge unterwegs sind, ist der plötzliche Stromausfall definitiv die Ursache für Ihre Korruption. Echte SSDs für Unternehmen und Industrie verfügen über Superkondensatoren , die die Stromversorgung lange genug aufrechterhalten, um Daten aus dem Cache in einen nichtflüchtigen Speicher zu verschieben, ähnlich wie batteriegepufferte und flashgepufferte RAID-Controller-Caches funktionieren .

Wenn Ihr Laufwerk kein Supercap hat, gehen die laufenden Transaktionen verloren, was zu einer Beschädigung des Dateisystems führt. ext3 wird wahrscheinlich mitgeteilt, dass sich alles auf einem stabilen Speicher befindet, aber das ist nur eine Funktion des Caches.

— ewwhite
quelle

Es tut Ihnen und allen, die dies befürwortet haben, leid, aber Sie liegen einfach falsch. Der Umgang mit dem Verlust laufender Schreibvorgänge ist genau das, wofür das Journal bestimmt ist. Solange das Laufwerk korrekt meldet, ob es über einen Schreibcache verfügt und Befehle zum Leeren befolgt, garantiert das Journal, dass die Metadaten nicht inkonsistent sind. Sie benötigen nur einen Supercap-Cache oder einen batteriegepufferten RAID-Cache, damit Sie den Schreibcache aktivieren können, ohne Barrieren aktivieren zu müssen, was zu Leistungseinbußen bei der Aufrechterhaltung der Datenkorrektheit führt.

— Psusi

@psusi Auf der verwendeten SSD ist der Cache wahrscheinlich explizit aktiviert oder es wird ein interner Puffer verwendet, unabhängig von der Einstellung für OS_level. Die Daten in diesem Cache entsprechen dem Schutz einer SSD mit Superkondensator .

— ewwhite

Die Daten im Cache müssen nicht geschützt werden, wenn Sie E / A-Barrieren aktivieren. Die meisten Laufwerke des Consumer-Typs werden mit standardmäßig deaktiviertem Schreib-Caching ausgeliefert. Sie müssen das Caching aktivieren, wenn Sie dies wünschen.

— Psusi

@pusi Alt jetzt, aber Sie erwähnen dies:

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.

Das ist die Sache: Aufgrund von Speichercontrollern, die dazu neigen, ältere Festplatten anzunehmen, werden SSDs manchmal darüber lügen, ob Daten gelöscht werden. Du brauchst das Supercap.

— Joel Coel

Sie haben Recht und Ihr Kollege liegt falsch. Wenn nichts schief geht, stellt das Journal sicher, dass Sie nie inkonsistente fs-Metadaten haben. Sie können mit überprüfen hdparm, ob der Schreibcache des Laufwerks aktiviert ist. Wenn dies der Fall ist und Sie keine E / A-Barrieren aktiviert haben (standardmäßig in ext3 deaktiviert, standardmäßig in ext4 aktiviert), ist dies die Ursache des Problems.

Die Barrieren werden benötigt, um zu erzwingen, dass der Schreibcache des Laufwerks zum richtigen Zeitpunkt geleert wird, um die Konsistenz aufrechtzuerhalten. Einige Laufwerke weisen jedoch ein schlechtes Verhalten auf und melden entweder, dass ihr Schreibcache deaktiviert ist, wenn dies nicht der Fall ist, oder ignorieren die Leerbefehle im Hintergrund. Dies verhindert, dass das Journal seine Arbeit erledigt.

— Psusi
quelle

-1 für Leseverständnis ...

— ewwhite

@ewwhite, vielleicht solltest du versuchen zu lesen und tatsächlich eine nützliche Antwort zu schreiben, anstatt diese kindische Beleidigung.

— Psusi

+1 Diese Antwort könnte wahrscheinlich verbessert werden, wie jede andere Antwort in einer QS. Aber liefert wenigstens etwas Licht und Hinweise. @Downvoters: Verbessern Sie die Antwort selbst oder kommentieren Sie mögliche Abläufe, aber das Ablehnen dieser Antwort ohne angemessene Begründung ist einfach widerlich!

— Alberto