it-swarm.com.de

fsck zeigt ext4-Dateisystemfehler an, jedoch nur beim Booten von der Systempartition

Ich habe ein Problem mit meiner ext4-Systempartition. Ich verwende 17.04 (von 16.10 aktualisiert), aber das Problem war bereits in 16.10 vorhanden.

Gelegentlich (am häufigsten nach dem Aufwecken des Systems aus dem Standby-Modus) stürzt das System mit einer Reihe von ext4-Dateisystemfehlern ab.

Jetzt beim Überprüfen des Dateisystems mit

Sudo fsck -n /dev/nvme0n1p2

fsck behauptet, dass das Dateisystem sauber ist

fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning!  /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
/dev/nvme0n1p2: clean, 434755/15089664 files, 46490132/60347136 blocks

Wenn ich jedoch eine Überprüfung erzwinge, erhalte ich eine ganze Reihe von Fehlern:

Sudo fsck -nf /dev/nvme0n1p2
fsck from util-linux 2.29
e2fsck 1.43.4 (31-Jan-2017)
Warning!  /dev/nvme0n1p2 is mounted.
Warning: skipping journal recovery because doing a read-only filesystem check.
Pass 1: Checking inodes, blocks, and sizes
Inodes that were part of a corrupted Orphan linked list found.  Fix? no

Inode 131275 was part of the orphaned inode list.  IGNORED.
Inode 135221 was part of the orphaned inode list.  IGNORED.
Inode 135244 was part of the orphaned inode list.  IGNORED.
Inode 135260 was part of the orphaned inode list.  IGNORED.
Inode 135263 was part of the orphaned inode list.  IGNORED.
Inode 135268 was part of the orphaned inode list.  IGNORED.
Deleted inode 135272 has zero dtime.  Fix? no

Inode 135274 was part of the orphaned inode list.  IGNORED.
Inode 135384 was part of the orphaned inode list.  IGNORED.
Inode 135396 was part of the orphaned inode list.  IGNORED.
Inode 135697 was part of the orphaned inode list.  IGNORED.
Inode 135711 was part of the orphaned inode list.  IGNORED.
Inode 135713 was part of the orphaned inode list.  IGNORED.
Inode 12059086 was part of the orphaned inode list.  IGNORED.
Inode 12061077 was part of the orphaned inode list.  IGNORED.
Inode 12062594 was part of the orphaned inode list.  IGNORED.
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
Block bitmap differences:  -(40927357--40927367) -(40927563--40927569) -(40940652--40940653) -(40940676--40940681) -(48296964--48296970) -(48296978--48296984) -(48304145--48304165) -(48304315--48304321) -(48326677--48326690) -(48326733--48326739) -(48326775--48326781)
Fix? no

Free blocks count wrong (13857004, counted=13856542).
Fix? no

Inode bitmap differences:  -131275 -135221 -135244 -135260 -135263 -135268 -135272 -135274 -135384 -135396 -135697 -135711 -135713 -12059086 -12061077 -12062594
Fix? no

Free inodes count wrong (14654909, counted=14654758).
Fix? no


/dev/nvme0n1p2: ********** WARNING: Filesystem still has errors **********

/dev/nvme0n1p2: 434755/15089664 files (0.3% non-contiguous), 46490132/60347136 blocks

Jetzt besteht mein Problem darin, dass ich diese Fehler nicht beheben kann, da es sich um meine Systempartition handelt, deren Bereitstellung ich nicht aufheben kann. Aber wenn ich von einem externen Laufwerk oder im Wiederherstellungsmodus boote, meldet fsck keine Fehler, auch mit -f. Nach dem Neustart meines Systems bleiben die Fehler jedoch bestehen. Ich bin derzeit ratlos, wie ich das Dateisystem reparieren kann. Jede Hilfe wäre sehr dankbar.

6
Maeher

Wenn Sie eine Dateisystemprüfung für ein ext4-Dateisystem erzwingen, das derzeit mit fsck -nf <filesystem> in den R/W-Modus eingebunden ist, werden immer Fehlermeldungen angezeigt, wie die von Ihnen veröffentlichten , beschädigten Orphan-Dateien Verknüpfte Liste , Gelöschter Inode ... hat null dtime ). Die Tatsache, dass fsck -n <filesystem> es als sauber meldet, ist hier etwas irreführend.

Der Grund, warum Sie diese Fehler im Wiederherstellungsmodus oder beim Booten von einem externen Laufwerk nicht sehen, ist einfach die Tatsache, dass in diesem Fall das betreffende Dateisystem nicht im R/W-Modus oder überhaupt nicht gemountet ist.

Die Manualpage für e2fsck gibt auch explizit an:

Beachten Sie, dass es im Allgemeinen nicht sicher ist, e2fsck auf gemounteten Dateisystemen auszuführen. Die einzige Ausnahme ist, wenn die Option -n angegeben ist und die Optionen -c, -l oder -L nicht angegeben sind. Selbst wenn dies sicher ist, sind die von e2fsck ausgedruckten Ergebnisse nicht gültig, wenn das Dateisystem eingehängt ist. Wenn e2fsck fragt, ob Sie ein eingehängtes Dateisystem überprüfen sollen, ist die einzig richtige Antwort "Nein". Nur Experten, die wirklich wissen, was sie tun, sollten in Betracht ziehen, diese Frage auf andere Weise zu beantworten.

Fazit : Wenn Sie beabsichtigen, das -f -Flag für fsck zu verwenden, stellen Sie sicher, dass Sie 100% verstehen, was es tut. Insbesondere die Verwendung auf einem bereitgestellten Dateisystem ist normalerweise nicht das, was Sie möchten.

Was die Ursache für ext4-Fehler beim Aufwachen aus dem Standby-Modus angeht, handelt es sich um ein ganz anderes Problem, das Sie anscheinend bereits gelöst haben. Aus Referenzgründen werde ich die Links, die Sie selbst gepostet haben, hier in einen Kommentar aufnehmen, da sie bei der Lösung Ihres ursprünglichen Problems hilfreich waren:

7
Sebastian Stark