Warum läuft FSCK auch dann, wenn Sie niemals ein unreines Herunterfahren haben?

man 8 tune2fs beantwortet eigentlich beide Fragen:

-c Max-Mount-Anzahl

Passen Sie die Anzahl der Mounts an, nach denen das Dateisystem von e2fsck (8) geprüft wird . Wenn max-mount- count 0 oder -1 ist, wird die Anzahl der gemounteten Dateisysteme von e2fsck (8) und dem Kernel ignoriert .

Durch die Staffelung der Mount-Zählwerte, bei denen Dateisysteme zwangsweise geprüft werden, wird vermieden, dass alle Dateisysteme bei der Verwendung von Journaled-Dateisystemen gleichzeitig geprüft werden.

Sie sollten die Folgen einer vollständigen Deaktivierung der mount-count-abhängigen Prüfung unbedingt berücksichtigen. Fehlerhafte Laufwerke, Kabel, Speicher und Kernelfehler können ein Dateisystem beschädigen, ohne das Dateisystem als fehlerhaft oder fehlerhaft zu kennzeichnen. Wenn Sie Journaling in Ihrem Dateisystem verwenden, wird Ihr Dateisystem niemals als verschmutzt markiert, daher wird es normalerweise nicht geprüft. Ein Dateisystemfehler, der vom Kernel erkannt wird, erzwingt immer noch einen fsck-Befehl beim nächsten Neustart. Es ist jedoch möglicherweise bereits zu spät, um einen Datenverlust an diesem Punkt zu verhindern.

Siehe auch die Option -i für die zeitabhängige Prüfung.

Das

-i Intervall zwischen Prüfungen [d | m | w]

Passen Sie die maximale Zeit zwischen zwei Dateisystemprüfungen an. Kein Suffix oder d wird die Zahl interpretieren intervall zwischen Kontrollen als Tage, m als Monate und w als Wochen. Ein Wert von Null deaktiviert die zeitabhängige Prüfung.

Es wird dringend empfohlen, entweder -c (mount-count-abhängig) oder -i (zeitabhängig) zu aktivieren, um das e2fsck (8) des Dateisystems regelmäßig zu überprüfen. Andernfalls kann es zu einer Beschädigung des Dateisystems (aufgrund defekter Festplatten, Kabel, Speicher oder Kernel-Fehler) kommen, die unbemerkt bleibt, was zu Datenverlust oder -beschädigung führen kann.

Wenn Sie die Häufigkeit der Überprüfungen (nach den max-mount-count-Werten oder den Schwellenwerten für das Intervall zwischen den Überprüfungen ) in Ihrem eigenen ext2 / ext3 / ext4-Dateisystem ermitteln möchten, können Sie den folgenden Befehl ausführen:

sudo dumpe2fs /dev/YOURDEV | grep -Ei '(mount count|interval|check)' 

Ersetzen Sie /dev/YOURDEVdurch die Partition, die Sie untersuchen möchten.

Beispielausgabe:

deltik@node51 [~]$ sudo dumpe2fs /dev/nvme0n1p3 | grep -Ei '(mount count|interval|check)' dumpe2fs 1.42.13 (17-May-2015) Mount count: 1 Maximum mount count: -1 Last checked: Tue Mar 15 13:30:00 2018 Check interval: 0 (<none>) 

Ist FSCK wirklich notwendig, auch wenn Sie niemals unreine Shutdowns hatten?

Kommt darauf an. Können Sie mit 100% Sicherheit garantieren, dass Sie nie haben alle unter dem Dateisystem zur Beschädigung von Daten im Speichersystem?

In der Regel ist eine Überprüfung des Dateisystems nach einem unsauberen Herunterfahren bestimmter Dateisysteme (besonders bei älteren Dateisystemen, meistens ext4) zwingend vorgeschrieben. Ein nicht sauberes Herunterfahren ist jedoch nicht die einzige Situation, die die internen Datenstrukturen des Dateisystems beschädigen kann. Nicht katastrophale Geräteausfälle (fehlerhafte Sektoren, fehlerhafte Firmware usw.) können die gleiche Art von Beschädigung verursachen. Daher ist es generell eine gute Idee, gelegentlich zu überprüfen, auch wenn Ihr System nicht abstürzt oder die Stromversorgung ausfällt.

Dies ist besonders wichtig bei ext4, weil:

• Wenn Sie Journaling verwenden (wenn Sie nicht wissen, ob Sie Journaling verwenden oder nicht, ist dies wahrscheinlich der Fall), wird das Dateisystem möglicherweise niemals auf andere Weise geprüft, da ein Journal-Dateisystem selbst nach einem unreinen Herunterfahren selbstkonsistent ist.
• Das Standardverhalten bei Fehlern in den Metadaten des Dateisystems zur Laufzeit besteht darin, das Problem einfach zu protokollieren und fortzufahren, als ob nichts passiert wäre. Dies bedeutet, dass im Vergleich zu anderen Dateisystemen (z. B. XFS, BTRFS oder ZFS) die Wahrscheinlichkeit geringer ist, dass Sie feststellen, dass ein Problem mit dem Dateisystem auftritt, bis es zu spät ist, um es zu beheben.