ext3 fsck Zeit gegen Partitionsgröße

Ich mache das Setup für eine große Speicherfarm und um die Notwendigkeit monatelanger Fscks zu vermeiden, ist mein Plan, den Speicher in zahlreiche kleinere Dateisysteme aufzuteilen (dies ist in Ordnung, da ich einen gut ausgebauten Dateibaum habe , so dass ich leicht getrennte Dateisysteme montiert haben 1/, 2/, 3/, 4/, etc.).

Meine Schwierigkeit besteht darin, eine Aufzählung der "vernünftigen" Größe eines Dateisystems zu finden, um die fsck-Zeiten ähnlich "vernünftig" zu halten. Obwohl ich mir völlig bewusst bin, dass die absolute Zeit für eine bestimmte Größe weitgehend von der Hardware abhängt, kann ich anscheinend keine Beschreibung der Kurvenform für ext3-fsck-Zeiten mit unterschiedlichen Dateisystemgrößen und der anderen Variablen finden ( Dauert ein Dateisystem voller Dateien in einem einzelnen Verzeichnis länger als eines mit 10 Dateien in jeweils Tausenden von Verzeichnissen in einem Baum, große Dateien gegen kleine Dateien, volles Dateisystem gegen leeres Dateisystem usw.).

Hat jemand Hinweise auf gut recherchierte Zahlen dazu? Andernfalls sollten Anekdoten zu diesen Themen zumindest dazu beitragen, meine eigenen Experimente zu leiten, falls dies erforderlich sein sollte.

BEARBEITEN : Zur Verdeutlichung: Unabhängig vom Dateisystem muss überprüft werden, ob bei den Metadaten ein Fehler auftritt. Ob zeit- oder mountbasierte Re-Fscks aktiviert sind oder benötigt werden, steht nicht zur Debatte. Der einzige Grund, warum ich nach Zahlen speziell für ext3 frage, ist, dass dies das wahrscheinlichste zu wählende Dateisystem ist. Wenn Sie ein Dateisystem kennen, das einen besonders schnellen fsck-Prozess hat, bin ich offen für Vorschläge, aber es muss eine robuste Option sein (behauptet, dass "Dateisystem X braucht nie fscking!" Lachend und verspottet wird). . Ich bin mir auch der Notwendigkeit von Backups bewusst, und der Wunsch nach fsck ist kein Ersatz für Backups. Es scheint jedoch wirklich, das Dateisystem zu verwerfen und aus dem Backup wiederherzustellen, wenn es fehlerhaft ist, anstatt es zu fscken.

Nach einer Arbeit von Mathur et al. (S. 29) wächst die e2fsck-Zeit linear mit der Anzahl der Inodes in einem Dateisystem nach einem bestimmten Punkt. Wenn der Graph etwas zu bieten hat, sind Sie mit Dateisystemen mit bis zu 10 Millionen Inodes effektiver.

Ein Wechsel zu ext4 würde helfen - unter der Bedingung, dass Ihr Dateisystem nicht bis zum Rand geladen ist, wo der Leistungsgewinn (aufgrund der Nichtprüfung von Inodes, die als nicht verwendet markiert sind) keine erkennbaren Auswirkungen hat.

Ich denke, Sie müssen Ihr eigenes Benchmarking durchführen. Eine schnelle Suche auf Google ergab nichts, außer dass ext4 viel schneller als ext3 fscks.

Erstellen Sie also einige ext3-Partitionen, 100 GB, 200 GB usw. bis zur verwendeten Festplattengröße. Dann füllen Sie sie mit Daten. Wenn Sie Daten verwenden können, die Ihren Produktionsdaten ähneln (Dateien pro Verzeichnis, Dateigrößenverteilung usw.), ist dies am besten. Beachten Sie, dass durch einfaches Kopieren von Dateien von einer anderen Partition oder einem Sicherungsgerät diese perfekt angelegt und defragmentiert auf der Festplatte abgelegt werden und Ihren Tests daher viele Suchzeiten für den Festplattenkopf fehlen, die durch viele Schreib- / Änderungs- / Löschvorgänge entstehen.

Sie müssen auch über parallele fscks nachdenken. Siehe die letzten Felder in / etc / fstab. Partitionen auf derselben physischen Festplatte sollten nacheinander ausgeführt werden. Es können mehrere Festplatten auf demselben Controller gleichzeitig ausgeführt werden. Achten Sie jedoch darauf, den Controller nicht zu überlasten und zu verlangsamen.

http://lmgtfy.com/?q=fsck+benchmark

Es sieht so aus, als ob fsck auf ext4-Dateisystemen erheblich schneller ist als auf ext3. Einige Berichte über ext4 fsck sind zehnmal oder sogar noch schneller als ext3.

Zwei interessante Artikel aus dieser Suche sind:

http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times/ undhttp://thunk.org/tytso/blog/2009/02/26/fast-ext4-fsck-times-revisited/

Gibt es einen Grund, warum Sie kein Dateisystem verwenden können, das Ihnen beim Neustart keine Zeit- oder Mount-Count-basierten Fscks aufzwingt?

(Die zeitbasierten fscks nerven mich wirklich - für einen Server mit langer Betriebszeit ist so ziemlich garantiert, dass Sie bei jedem Upgrade des Kernels einen vollständigen fsck durchführen müssen).

Auf jeden Fall ist XFS eines der Journaling-Dateisysteme, die kein fsck erzwingen. einen Blick wert.