Wann ist fsck gefährlich?

37

Kürzlich habe ich gesehen, dass das Root-Dateisystem eines Computers in einem Remote-Rechenzentrum aufgrund von Konsistenzproblemen wieder schreibgeschützt bereitgestellt wird.

Beim Neustart wurde dieser Fehler angezeigt:

UNEXPECTED INCONSISTENCY: RUN fsck MANUALLY (i.e., without -a or -p options)

Nachdem Sie fsck wie vorgeschlagen ausgeführt und die Korrekturen manuell mit übernommen haben Y, wurden die Fehler behoben und das System ist nun in Ordnung.

Nun, ich denke, es wäre interessant, wenn fsck so konfiguriert wäre, dass es alles automatisch ausführt und repariert, da die einzige Alternative in einigen Fällen (wie dieser) darin besteht, persönlich zum entfernten Rechenzentrum zu gehen und eine Konsole an den betroffenen Computer anzuschließen.

Meine Frage ist: warum fragt fsck standardmäßig nach manuellen Eingriffen? Wie und wann wäre eine Korrektur durch ein solches Programm unsicher? In welchen Fällen möchte der Systemadministrator eine vorgeschlagene Korrektur für einige Zeit beiseite lassen (um andere Vorgänge auszuführen) oder sie insgesamt abbrechen?

— scristalli
quelle

15

Wenn die Entwickler zu 100% sicher wären, dass der Fehler automatisch behoben werden kann, wäre dies nicht in erster Linie ein Fehler.

— user253751

42

fsckVerursacht definitiv mehr Schaden als Nutzen, wenn die zugrunde liegende Hardware irgendwie beschädigt ist. Eine fehlerhafte CPU, ein fehlerhafter RAM, eine sterbende Festplatte, ein fehlerhafter Festplattencontroller ... in diesen Fällen ist mehr Korruption unvermeidlich.

Im Zweifelsfall ist es eine gute Idee, ein Image der beschädigten Festplatte mit dd_rescueeinem anderen Tool zu erstellen und dann zu prüfen, ob Sie das Image erfolgreich reparieren können. Auf diese Weise steht Ihnen immer noch das ursprüngliche Setup zur Verfügung.

— Janne Pikkarainen
quelle

4

Ich habe viel mit fehlerhafter Hardware gearbeitet und bin damit einverstanden. Das Letzte, was ich tun möchte, ist fsck, wenn der Verdacht auf eine schlechte Hardware besteht. Ich habe auch ein Low-Power-Ereignis und eine anschließende Wiederherstellung gesehen, die durch die automatische fsck stark verzögert wurde.

— Jorfus

Um ein konkretes Beispiel zu geben: Ich habe an einer Maschine mit einem Plattencontroller gearbeitet, der "zufällig" (ungefähr 1 Mal in 10 ^ 5) einen Lese- oder Schreibzugriff auf Block XXXXXXYY auf einem beliebigen Gerät in einen Schreibzugriff auf Block 000000YY auf der Festplatte umwandelte erstes Gerät. Das heißt, es wurden häufig strukturierte falsche und unstrukturierte falsche Daten in den Bootsektor und verschiedene kritische Dateisystemstrukturen der Bootdiskette gestrahlt. Das Ausführen von fsck in einer solchen Situation (Millionen von Lesevorgängen) kann die verbleibende Chance zur Wiederherstellung von Daten eliminieren.

— Eric Towers

2

1 in 10 ^ 5 ist eine Menge ... das sind 10 Byte je Mb.

— Nelson

1

@ Nelson: Es ist irgendwie ... Die Einheit gibt es "Single Block Transfers", nicht "Bytes". Zehn fehlerhafte Blockschreibvorgänge pro Million Blöcke (und Blöcke sind deutlich größer als Bytes).

— Eric Towers

21

Sie haben ein Beispiel gesehen, in dem es fsckfunktioniert hat, aber ich habe mehr als genug beschädigte Dateisysteme gesehen, in denen es überhaupt nicht erfolgreich funktioniert hat. Wenn dies vollautomatisch funktioniert, haben Sie möglicherweise keine Möglichkeit, einen ddSpeicherauszug oder Ähnliches zu erstellen, was in vielen Fällen eine hervorragende Idee wäre, bevor Sie versuchen, eine Reparatur durchzuführen.

Es ist niemals eine gute Idee , überhaupt so etwas Automatisches auszuprobieren.

Oh, und moderne Server sollten über Remote-Konsolen oder zumindest unabhängige Rettungssysteme verfügen, um sich von so etwas zu erholen, ohne ein KVM-Rack an den Server zu schleppen.

— Sven
quelle

7

Eigentlich ist es keine gute Idee, so etwas " nie, nie " zu sagen , wenn es nicht stimmt. Anwendungsfall, in dem es eine gute Idee ist: Die Hauptpartitionen des Servers können im Falle eines Problems relativ schnell von Grund auf neu erstellt werden. Tatsächlich wird auf wichtige Daten über ein Remote-Dateisystem zugegriffen, wobei für diese Daten die entsprechende Redundanz vorhanden ist. Ich möchte lieber die Chance nutzen, dass fsck -p /und fsck -p /varusw. einwandfrei funktionieren und der Server ohne manuelle Eingriffe hochgefahren wird, und das Risiko eingehen, dass die Partitionen, die ich bei Bedarf einfach neu erstellen kann, eine kleine Katastrophengefahr darstellen, die nicht bei null Prozent liegt .

— TOOGAM

1

Wenn das System einfach neu installiert werden kann, mache ich das einfach ...

— Sven

1

Das würde länger dauern. Optionen sind: A) Riskieren Sie es automatisch. B) fsckLassen Sie jemanden putzen, und dann funktioniert alles einwandfrei. Dauert etwa 2 Minuten, wenn das so ist. Ausfallzeit bis dies passiert. C) Lassen Sie das Betriebssystem erneut installieren. Dauert 30+ Minuten. Sie wählen Option C? Möglicherweise besteht ein wesentlicher Unterschied darin, dass ich in fsckeinem größeren Prozentsatz der Zeit gearbeitet habe, als Sie in Ihrer Antwort angegeben haben. Mein wichtigster Punkt war nicht das Systemdesign (dieses billige System verwendet keine Remote-Konsole), sondern nur der Satz " Nie, nie " war zu stark, um genau zu sein

— TOOGAM

Lassen Sie uns einfach zustimmen, nicht zuzustimmen.

— Sven

0

Zuallererst müssen Sie verstehen, dass bei modernen (journalisierten) Dateisystemen ein Systemabsturz das Dateisystem nicht beschädigt und beim Booten kein fsck erforderlich ist.

Ext3, Ext4, ZFS, btrfs, xfs und alle modernen FS sind nach einem Absturz oder einem Systemreset zu 100% konsistent.

Nicht journalisierte FS wie ext2 oder vfat sind eine große NOGO für ein System-Rootfs.

Wenn Ihr System beim Booten ein fsck benötigt, sollten Sie sich fragen: Was war der Grund dafür?

Sie sollten anschließend Ihre Kernel-Protokolle untersuchen, um herauszufinden, wann und was passiert ist. Sie sollten auch in den Protokollen nach dem Zeitpunkt suchen, zu dem der Fehler aufgetreten ist. Sie sollten Ihre Festplatten mit smartctl überprüfen. Etc ... Wenn Sie ein Fsck für eine journalisierte Fs benötigen, ist es so gut wie sicher, dass Ihre Hardware ausfällt, vorausgesetzt, die Fs wurde nicht von einem Administrator (mit Tools auf Blockebene wie dd) oder durch einen Fehler beschädigt.

Daher ist es albern, fsck zu verwenden, um das Problem zu "beheben", ohne die Grundursache zu untersuchen und zu beheben (durch Ersetzen / Aktualisieren der fehlerhaften Hardware / Firmware / Software).

Einen Fsck zu machen, den Boot abzuschließen und glücklich zu sein, ist, gelinde gesagt, naiv. Ich frage mich, was Sie mit "fsck work" meinen, wenn ich sage, dass ich in einem größeren Prozentsatz der Zeit fsck work hatte, als Sie angegeben haben. Möglicherweise hat fsck Ihren fs durch den Verlust einiger Dateien und Daten wieder in einen konsistenten Zustand versetzt ... Haben Sie einen Vergleich mit einer Sicherung angestellt? Viele Leute verlieren Dateien oder bekommen Dateidatenkorruption, ohne es zu merken ...

— François Scheurer
quelle