Bootverzögerungen durch fsck

Das Problem 

Gelegentlich wird man besonders bei Verwendung von sehr großen Filesystemen auf das Problem stoßen, dass der Bootvorgang hin und wieder einmal sehr lange dauert. ( manchmal 5 und mehr Minuten länger als normal ) Das liegt daran, das Filesysteme hin und wieder einmal während des Bootvorganges überprüft werden.

Hier soll das Problem an Hand des ext3-Filesystems erklärt und aufgezeigt werden, sowie die Möglichkeit der optimalen Einstellungen für solche Filesysteme vorgestellt werden.

kompletter Filesystemcheck bei ext3

Das ext3 Filesystem

Beim ext3-Filesystem handelt es sich um eine Erweiterung des ext2-Filesystem, genauer um die Erweiterung eines Filesystem-Journals im ext2-Filesystemen sowie kleine weitere Änderungen von Eigenschaften und Möglichkeiten. Der grundsätzliche Aufbau beider Filesysteme ist absolut gleich. Aus diesem Grunde lassen sich ext2-Filesysteme auch problemlos ohne aufwendige Konvertierung in ext3-Filesysteme umwandeln und umgekehrt. Auch die Befehle und Tools sind für beide Filesysteme die selben, wie man hier an Hand der gleichen Inode schnell erkennen kann.

LINUX:/ #  ls -il /sbin/fsck.ext? /sbin/mkfs.ext?
442822 -rwxr-xr-x  3 root root 131344 Apr  6  2004 /sbin/fsck.ext2
442822 -rwxr-xr-x  3 root root 131344 Apr  6  2004 /sbin/fsck.ext3
442757 -rwxr-xr-x  3 root root  31080 Apr  6  2004 /sbin/mkfs.ext2
442757 -rwxr-xr-x  3 root root  31080 Apr  6  2004 /sbin/mkfs.ext3

Das Filesystem-Journal

Ein Journal kann man sich vorstellen wie ein Aufgabenbuch. Hier wird zuerst einmal festgehalten was gemacht werden soll, erst dann werden die einzelnen Arbeiten ausgeführt und der Aufgabeneintrag danach wieder entfernt. Es werden also zuerst alle anstehenden Änderungen am Filesystem in eine spezielle Datei, dem Journal, vermerkt und auf die Festplatte geschrieben, bevor sie wirklich am Filesystem ausgeführt werden. Auf dem ersten Blick ist das doppelte Arbeit, die auch wirklich etwas Rechenzeit bei Änderungen an den Dateien verbraucht, hat aber den Vorteil, die Daten im Filesystem bleiben auch zB. bei einem plötzlichen Rechnerabsturz konsistent auf der Festplatte stehen. Der Rechner kann dann an Hand des Journals erkennen was die letzte Operation am Filesystem war, oder hätte sein sollen, und kann diese wiederholen und noch im Journal ausstehende Änderungen am Filesystem durchführen. Der Vorteil macht sich nach einem solchem Systemabsturz dann beim Mounten bemerkbar. Ein Filesystem kann nur eingehängt werden wenn es clean ist, also entweder sauber ausgehängt wurde oder dieses Flag mit Hilfe eines fsck gesetzt worden ist. Ein ext2-Filesystem muss also nach einem Systemabsturz erst einmal komplett überprüft werden. Das kann je nach Größe des Filesystems einige Minuten, in extrem großen Filesystemen aber auch Stunden dauern, Der Bootvorgang wird hier solange verzögert bis das Filesystem eingehängt werden kann. Beim Journalfilesystem braucht fsck nur das Journal abzuarbeiten und ist innerhalb von wenigen Sekunden fertig und kann das Cleanflag setzen und der Bootvorgang geht sofort weiter.

Neben dem oben beschrieben kompletten Journaling ( die Änderungen werden wirklich 2 Mal auf die Festplatte geschrieben, einmal ins Journal und dann noch einmal ins Filesystem ) wie es in frühen Versionen von ext3 Standard war, gibt es noch 2 weitere Methoden das Journal zu benutzen, den Modus ordered und den Modus writeback. Diese stellen einen Kompromiss zwischen Geschwindigkeit und Datensicherheit dar. Welcher Modus für das Journal verwendet wird, wird mit dem mount-Optionen festgelegt. Default ist ordered als akzeptabler Kompromiss zwischen Zuverlässigkeit und Geschwindigkeit eingestellt.

Weitere Informationen dazu in Manpage mount Aus den CHANGES-files alter Distributionen stammt diese Beschreibung der einzelnen Optionen

    "mount -o data=journal"
        Journals all data and metadata, so data is written twice. This
        is the mode which all prior versions of ext3 used.

    "mount -o data=ordered"
        Only journals metadata changes, but data updates are flushed to
        disk before any transactions commit. Data writes are not atomic
        but this mode still guarantees that after a crash, files will
        never contain stale data blocks from old files.

    "mount -o data=writeback"
        Only journals metadata changes, and data updates are entirely
        left to the normal "sync" process. After a crash, files will
        may contain stale data blocks from old files: this mode is
        exactly equivalent to running ext2 with a very fast fsck on reboot.

Optionen für einen kompletten Filesystemcheck

Werte beim Anlegen des Filesystems

Beim Anlegen eines ext2 oder ext3 Filesystems wird per Zufallsgenerator innerhalb eines bestimmten Bereiches festgelegt, nach wieviel Mounts dieses Filesystem beim mounten komplett überprüft werden soll, auch wenn das Filesystem der Meinung ist, ich bin clean. Bei sehr großen Filesystemen dauert ein solcher Filesystemcheck dann Minuten oder auch Stunden. Das ist bei einem Journal-Filesystem aber wichtig, das es hin und wieder einmal komplett geprüft wird, denn nach einem Crash zB. wird ja nur das Journal abgearbeitet und nicht wirklich das gesamte Filesystem nach eventuellen Fehlern überprüft. Es können also hier durchaus kleinere Fehler dennoch im Filesystem sein, obwohl der Filesystem der Meinung ist, es ist sauber. Es werden dort also Zufallswerte für Anzahl der Mounts und 180 Tage für Anzahl der Tage festgelegt. Nach dem Ablauf eines dieser Werte, wird das Filesystem beim automatischen mount beim booten automatisch komplett überprüft. Zufallszahlen deshalb, damit wenn mehrere Filesysteme gleichzeitig anlegt werden, diese dann nicht alle auf einmal geprüft werden müssen, was sonst dann viel zu lange dauern würde und es auch nicht notwendig ist, alle Filesysteme gleichzeitig zu prüfen.

Ausgabe beim Anlegen eines ext3 Filesystemes könnte zB so hier aussehen Code:

This filesystem will be automatically checked every 33 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Werte auslesen

Anzeigen lassen kann man sich die Werte eines ext2/ext3 Filesystems mit dumpe2fs.

LINUX:/ # dumpe2fs -h /dev/sdb3
dumpe2fs 1.34 (25-Jul-2003)
Filesystem volume name:   <none>
Last mounted on:          <not available>
Filesystem UUID:          655d8084-3830-4006-9c9b-c70fe223bac8
Filesystem magic number:  0xEF53
Filesystem revision #:    1 (dynamic)
Filesystem features:      has_journal filetype needs_recovery sparse_super
Default mount options:    (none)
Filesystem state:         clean
Errors behavior:          Continue
Filesystem OS type:       Linux
Inode count:              1144640
Block count:              2285246
Reserved block count:     114262
Free blocks:              1177002
Free inodes:              1144593
First block:              0
Block size:               4096
Fragment size:            4096
Blocks per group:         32768
Fragments per group:      32768
Inodes per group:         16352
Inode blocks per group:   511
Filesystem created:       Sun Jun  4 18:00:03 2006
Last mount time:          Mon Dec 25 14:22:14 2006
Last write time:          Mon Dec 25 14:22:14 2006
Mount count:              3
Maximum mount count:      20
Last checked:             Mon Dec 25 11:41:31 2006
Check interval:           15552000 (6 months)
Next check after:         Sat Jun 23 12:41:31 2007
Reserved blocks uid:      0 (user root)
Reserved blocks gid:      0 (group root)
First inode:              11
Inode size:               128
Journal inode:            8
Default directory hash:   tea
Directory Hash Seed:      0d2f6350-84ae-4784-b3e9-db6437d3395e

Aus folgenden Abschnitt kann man erkennen, wann das Filesystem das letzte mal geprüft wurde und wann es wieder geprüft werden muss.

Mount count:              3
Maximum mount count:      20
Last checked:             Mon Dec 25 11:41:31 2006
Check interval:           15552000 (6 months)
Next check after:         Sat Jun 23 12:41:31 2007

In diesem Beispiel hier also entweder nach dem 23. Juni Mittags oder nach 17 weiteren Mounts je nach dem was eher eintritt.

Werte manuell neu setzen

Den Wert maximale Anzahl der mounts kann man zB. ändern mit

LINUX:/ # tune2fs -c 50 /dev/sdb3
tune2fs 1.34 (25-Jul-2003)
Setting maximal mount count to 50

ebenso kann man auch die maximale Anzahl der Tage änderen, nach deren Ablauf beim nächsten Mount wieder geprüft werden soll. (360d sind hier 360 Tage )

LINUX:/ # tune2fs -i 360d  /dev/sdb3
tune2fs 1.34 (25-Jul-2003)
Setting interval between check 31104000 seconds

Komplettes ausschalten beider Optionen dann analog

tune2fs -i 0 -c 0 /dev/PARTITION

es lassen sich auch noch andere Parameter eines ext2/ext3-Filesystems mit tune2fs ändern. Die Manpage von tune2fs ist hierfür der erste Anlaufpunkt.

Welche Werte sind nun für mich optimal ?

Kommt ganz darauf an, ist es auch gleichzeitig das Rootfilesystem oder ein anderes Systemfilesystem oder ist ein Home oder ein anderes Datenfilesystem, wird der Rechner jetzt täglich gebootet, oder läuft er monatelang durch und vor allem wie groß ist das Filesystem damit man eine ungefähre Vorstellung davon hat, wie lange es dann dauert?

Bei einem Rootfilesystem sollte man es auf gar keinen Fall komplett abschalten, da dort fsck nur schlecht per Hand angestoßen werden kann. Ein reines Datenfilesystem, hier könnte man es auch durchaus komplett ausschalten, (ist aber ausdrücklich nicht empfohlen) dann sollte aber dennoch hin und wieder mal ein komplettes fsck per Hand darüber laufen, spätestens so nach 3 bis 5 Systemcrash oder harten Ausschalten des Systems.

fsck -f /dev/PARTITION

Ansonsten den Wert so einstellen, dass ca. nach einem halben Jahr spätestens einmal überprüft wird. Also bei täglichem Booten oder sogar mehrfachen bootens pro Tag, dann kann man den Maxboot-Count hochschrauben oder mit -c 0 auch gleich ganz ausschalten. Der Tageszähler auf 120-180 Tage einstellen.

Handelt es sich um einen Server, der normalerweise selten rebootet wird, dann die Zeit mit -i 0 ausschalten und Maxboot auf zB. 10 stellen.

Wenn ein Server der normalerweise überhaupt nicht rebootet wird, so eingestellt wird, dass er bei jedem booten dann den Filesystemcheck durchführt, ist das zwar erstmal optimal eingestellt, man sollte sich aber dann auch darüber klar sein, gibt es irgendwelche Probleme mit diesem Rechner und dieser muss zB. bei einer Reparatur 10 Mal hintereinander gebootet werden, dann werden dann auch 10 Mal die Filesysteme überprüft. Auch solche Unvorhersehbarkeiten sollte man durchaus mit in seine Überlegungen einfließen lassen.

Wenn man sowieso mal gerade Wartungsarbeiten an seinem System ausführt und das Filesystem gerade nicht gemountet ist, dann kann man sich bei sehr großen Filesystemen auch hier mal unabhängig der eingestellten Werte zu einem manuell angestoßenen Filesystemcheck entschließen und so den Zeitpunkt für einen lange dauernden Filesystemcheck in eine günstigere Zeit verschieben.

Ein ext3 sollte aber eben hin und wieder einmal komplett gescannt werden, ob man das jetzt per Hand machen will, und es dann doch wieder vergisst, oder automatisch mit der Gefahr, dass es gerade dann passiert wenn man es überhaupt nicht gebrauchen kann, ist das Problem eines jeden Administrators selbst. Jedenfalls sollte man sich bei größeren Filesystemen (20 GB und größer) diese Werte mal anschauen und dann entscheiden ob sie entsprechend ihrer Verwendung nicht doch optimiert werden müssten.

Weitere Links

• Suse bootet manchmal langsam!?