Auf großen Dateisystemen wird fsck ausgeführt


13

Ich kümmere mich um eine alte Debian-Linux-Box (mit Etch) mit nur 512 MB RAM, aber viel externem Speicher. Ein ext3-Dateisystem hat eine Größe von 2,7 TB, und fsck kann es nicht überprüfen, da nicht genügend Arbeitsspeicher zur Verfügung steht, mit einem Fehler wie dem folgenden:

   Fehler beim Zuweisen des Verzeichnisblockarrays: Speicherzuweisung fehlgeschlagen
   e2fsck: abgebrochen

Ich habe eine Swap-Partition mit 4 GB hinzugefügt, die immer noch nicht vollständig ist. Dies ist jedoch ein 32-Bit-Kernel, sodass ich nicht erwarte, dass das Hinzufügen weiterer Partitionen helfen wird.

Gibt es außer dem Booten in einen 64-Bit-Kernel noch andere Möglichkeiten, fsck zu veranlassen, seine Prüfung abzuschließen?

Antworten:


12

Ein 64-Bit-Kernel und große Mengen an RAM ermöglichen es dem fsck, schön und schnell fertig zu werden. Alternativ gibt es jetzt eine Option in e2fsck, die es anweist, alle Zwischenergebnisse in einem Verzeichnis statt im RAM zu speichern, was immens hilfreich ist. Erstellen Sie /etc/e2fsck.confmit folgenden Inhalten:

[scratch_files]
directory = /var/cache/e2fsck

(Und stellen Sie natürlich sicher, dass das Verzeichnis vorhanden ist und sich auf einer Partition mit einigen GB freiem Speicherplatz befindet.) e2fsck wird SLLOOOOWWWWWWW ausführen, aber zumindest wird es abgeschlossen.

Natürlich funktioniert dies nicht mit dem Root-FS, aber wenn Sie Swap haben, haben Sie es trotzdem geschafft, den Root-FS zu mounten.


6

Am Ende habe ich versucht, was Womble vorschlug. Hier sind einige weitere Details, die nützlich sein können, wenn Sie wie ich diese neue Funktionalität in e2fsck noch nicht gesehen haben.

Die Konfigurationsoption "scratch_files" für e2fsck wurde irgendwann in der Version 1.40.x verfügbar. (In unserem Fall mussten wir auf die neueste Debian-Distribution aktualisieren, um diese Funktionalität zu erhalten.)

Neben der vorgeschlagenen Option "directory = / var / cache / e2fsk" gibt es einige weitere Konfigurationsoptionen zur Feinabstimmung der Verwendung des Arbeitsspeichers. Ich habe "dirinfo = false" verwendet, da das Dateisystem eine große Anzahl von Dateien, aber keine so große Anzahl von Verzeichnissen hatte. Wenn die Situation umgekehrt wäre, wäre die Option "icount" angemessen. Diese Optionen wurden alle in der Manpage für e2fsck.conf dokumentiert.

Übrigens hat Ted T'so über diese Optionen in diesem Thread geschrieben .

Ich fand, dass e2fsck extrem langsam lief, viel mehr als von Ted vorhergesagt. Es lief die meiste Zeit mit einer CPU-Auslastung von 99,9% (auf einem extrem langsamen alten Prozessor), was darauf hindeutet, dass das Speichern dieser Datenstrukturen auf der Festplatte anstelle des Arbeitsspeichers nicht die Hauptursache für die Verlangsamung war. Möglicherweise hat etwas anderes an dem, was im Dateisystem gespeichert war, e2fsck besonders langsam gemacht. Am Ende habe ich die Prüfung des Dateisystems vorerst abgebrochen. Das Dateisystem sollte überprüft werden, hatte jedoch (soweit ich weiß) keine Fehler. Ich werde es daher zu einem günstigeren Zeitpunkt überprüfen, wenn wir uns einen einwöchigen Ausfall leisten können.


Ich frage mich, ob btrfs das besser kann. ext4-Werkzeuge waren eindeutig nicht maßstabsgetreu gebaut. Ich hatte vor kurzem dieses Problem mit 2 GB RAM
user1133275
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.