FSCK Best Practices

Aus Thomas-Krenn-Wiki
Wechseln zu: Navigation, Suche

Dateisystem-Checks oder File System Checks (FSCK) prüfen Dateisysteme auf ihre Konsistenz. In der Regel ist ein Check für Journaling Dateisysteme wie Ext3, Ext4 oder XFS schnell durchgeführt, da das Metadaten Journal für einen konsistenten Zustand sorgt. Dennoch kann es zu Situationen kommen, in denen ein Dateisystem korrupt wird und repariert werden muss. Ein regelmäßiger FSCK wird auf Server-Systemen zur Vorbeugung von Dateisystem-Problemen empfohlen.

Periodischer Check unter Ubuntu

Ubuntu hat mit dem Release von Ubuntu 12.04 Precise den periodischen Dateisystem-Check (FSCK) deaktiviert.[1]

  • Bis zu Ubuntu 12.04 wurde FSCK in regelmäßigen Abständen beim System-Boot ausgeführt. Dazu wurden max-mount-counts und interval-between-checks beim Erzeugen des Dateisystems auf bestimmte Werte gesetzt:
$ sudo tune2fs -l /dev/sda1 | egrep -i "mount count|Check interval|Last|Next"
Mount count:              2
Maximum mount count:      39
Last checked:             Mon Jun 29 20:23:44 2015
Check interval:           15552000 (6 months)
Next check after:         Sat Dec 26 19:23:44 2015
  • Ab 12.04 finden Sie folgende Ausgabe vor, -1 bei max-mount-counts und 0 bei interval-between-checks deaktivieren den periodischen FSCK:
$ sudo tune2fs -l /dev/sda1 | egrep -i "mount count|Check interval|Last|Next"
Last mounted on:          /
Mount count:              80
Maximum mount count:      -1
Last checked:             Fri Jul 18 21:27:32 2014
Check interval:           0 (<none>)

Hinweis: Generell wird in Server-Umgebungen empfohlen, Datei-Systeme regelmäßig zu überprüfen. Nähere Informationen dazu finden Sie auch in:

Periodischen FSCK aktivieren

Achtung: Unter Umständen empfiehlt es sich auf Server-Systemen nicht den periodischen, sondern den manuellen Weg eines FSCKs zu gehen. Bei größeren Datei-Systemen kann ein FSCK durchaus länger dauern. Erreichen Sie durch einen Reboot den Mount-Count oder überschreiten Sie das Intervall zwischen Checks, wird beim Boot ein FSCK durchgeführt, während dem der Server nicht verfügbar ist! Beim manuellen Weg bestimmen Sie, wann der FSCK läuft.

Die Verwendung von LVM erlaubt außerdem den FSCK auf einen Snapshot abzusetzen. Die Downtime des Produktiv-Dateisystems beschränken Sie dadurch auf ein Minimum. Siehe dazu auch #Dateisystem-Check mit LVM Snapshot.

Voraussetzung fstab

In der fstab muss für den periodischen Check das pass o.a. fs_passno Feld richtig gesetzt sein.[2] Für das root Dateisystem wird standardmäßig 1 gesetzt, weitere Dateisysteme versieht man am besten mit 2:

$ sudo vi /etc/fstab
# / was on /dev/sda1 during installation
UUID=410ffeb7-f200-4d44-9517-d1b0926bd574 /               ext4    errors=remount-ro 0       1
# /home was on /dev/sda2 during installation
UUID=30995b90-3348-4de3-905b-593f7e2de487 /home           ext4    defaults        0       2

Einstellungen vornehmen

Um den periodischen FSCK beim Boot zu aktivieren, passen Sie mit tune2fs die Werte max-mount-counts und interval-between-checks an:

  1. max-mount-counts: Anzahl der mount-Vorgänge, nach denen das Filesystem automatisch überprüft wird.
  2. interval-between-checks: Maximal vergangene Zeit zwischen zwei Checks.
$ sudo tune2fs -c 60 /dev/sda1
tune2fs 1.42.9 (4-Feb-2014)
Setting maximal mount count to 60
$ sudo tune2fs -i 30d /dev/sda1
tune2fs 1.42.9 (4-Feb-2014)
Setting interval between checks to 2592000 seconds

FSCK beim Boot erzwingen

Hinweis: Die Einstellungen des pass o.a. fs_passno Feld (vgl. #Voraussetzung fstab) werden beim erzwungenen FSCK ignoriert! Es werden alle Dateisysteme aus der fstab geprüft.

Um beim nächsten Reboot einen FSCK zu erzwingen, wird die Datei /forcefsck erstellt:

$ sudo touch /forcefsck

Der nächste Boot-Vorgang führt einen FSCK durch:

Fsck-at-boot.png

Fortschrittsanzeige beim Booten

Ein Ubuntu Bug verhindert, dass FSCK Meldungen im eigentlich dafür vorgesehenen Log geloggt werden:

Um dennoch mehr Informationen zum FSCK beim Boot zu erhalten, kann für den mountall Upstart Job --verbose eingestellt werden:

  • Direkt im Upstart Script
    • Hier wird --verbose hinzugefügt
$ sudo vi /etc/init/mountall.conf
[...]
exec mountall --daemon $force_fsck $fsck_fix $debug_arg --verbose
  • Als Grub Option
    • Hier wird --verbose für alle Upstart Jobs aktiviert
$ sudo vi /etc/default/grub
[...]
GRUB_CMDLINE_LINUX_DEFAULT="--verbose"

Nach dem Aktivieren erhalten Sie eine Fortschrittsanzeige beim Booten:

Fsck-progress-at-boot.png

Außerdem sind die Log-Meldungen in der Datei mountall.log enthalten:

$ sudo grep fsck /var/log/upstart/mountall.log
fsck from util-linux 2.20.1
fsck / [173] exited normally

Auto Repair

Achtung: Die folgende Option bewirkt beim Auftreten von Fehlern ein Auto-Repair. Nicht in jeder Situation ist ein automatisches Reparieren von Fehlern gewünscht und sinnvoll!

$ sudo vi /etc/default/rcS
[...]
# automatically repair filesystems with inconsistencies during boot
FSCKFIX=yes

Standard-Einstellungen für neue Dateisysteme

Die Standard-Einstellungen für neu angelegte Dateisysteme nehmen Sie in der Datei mke2fs.conf vor. Per default ist der periodische Check von Dateisystemen deaktiviert, um ihn zu aktivieren setzen Sie enable_periodic_fsck auf 1:

$ sudo vi /etc/mke2fs.conf
[defaults]
        base_features = sparse_super,filetype,resize_inode,dir_index,ext_attr
        default_mntopts = acl,user_xattr
        enable_periodic_fsck = 1
[...]

Dadurch wird bei neuen Dateisystemen der FSCK automatisch eingerichtet:

$ sudo mkfs.ext4 /dev/loop0
[...]
This filesystem will be automatically checked every 23 mounts or
180 days, whichever comes first.  Use tune2fs -c or -i to override.

Manueller Filesystem Check

Einen manuellen FSCK starten Sie für ext4 mit fsck.ext4 aus dem Package e2fsprogs.[3] Die Namen der anderen Werkzeuge, z.B. für XFS finden Sie im Artikel Linux Dateisysteme.

Idealerweise wird ein FSCK nur auf nicht eingehängte Dateisysteme gestartet. In der Manpage findet sich dazu:[4]

Note that in general it is not safe to run e2fsck on mounted filesystems. The only exception is if the -n option is specified, and -c, -l, or -L options are not specified. However, even if it is safe to do so, the results printed by e2fsck are not valid if the filesystem is mounted.

Sollte sich das Dateisystem aktuell im Zustand clean befinden, muss der FSCK mit -f gestartet werden:

$ sudo fsck.ext4  /dev/loop0
e2fsck 1.42.9 (4-Feb-2014)
/dev/loop0: clean, 11/7680 files, 2370/30720 blocks
$ sudo fsck.ext4 -f /dev/loop0
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/loop0: 11/7680 files (9.1% non-contiguous), 2370/30720 blocks

Nicht interaktiver Dateisystem-Check

Die Option -n führt einen FSCK im read-only Modus durch und sieht für alle auftretenden Fragen No als Antwort vor. Die Option eignet sich daher, um nicht interaktiv einen FSCK zu starten - z.B. regelmäßig, automatisiert über einen Cron-Job. Auch in diesem Fall darf aber das Dateisystem nicht gemountet sein!

Dateisystem-Check mit LVM Snapshot

Der Einsatz von LVM erlaubt es Dateisystem-Checks mit Hilfe eines Snapshots durchzuführen. Dadurch muss das zu prüfende Device nicht für die Dauer des Checks ausgehängt werden. Es genügt, wenn das zu prüfende Dateisystem zum Erstellen des Snapshots ausgehängt wird. Theoretisch wäre auch ein LVM-Snapshot eines eingehängten Dateisystems möglich, sauberer und wirklich konsistent ist der Snapshot aber nur, wenn das Logical Volume nicht gemountet ist.

Den Weg für einen FSCK über einen LVM Snapshot empfiehlt übrigens auch Theodore Ts'o in Mailing List Posts.[1][5]

Hinweis: Die lazy Option kann hilfreich sein, wenn Benutzer aktuell mit dem Dateisystem arbeiten. Bei einem Lazy-Unmount werden Dateisystem-Ressourcen dann freigegeben, wenn sie nicht von Benutzern belegt werden. Man kann zuvor auch mit lsof prüfen, ob ein Dateisystem aktuell noch benutzt wird. Im folgenden Beispiel ist ein Aushängen nicht möglich, da sich ein Benutzer noch im Verzeichnis befindet:

# lsof | grep -i mnt
bash       6963            root  cwd       DIR              252,0     1024          2 /mnt
lsof      14456            root  cwd       DIR              252,0     1024          2 /mnt
grep      14457            root  cwd       DIR              252,0     1024          2 /mnt
lsof      14458            root  cwd       DIR              252,0     1024          2 /mnt
# umount /mnt
umount: /mnt: device is busy.
        (In some cases useful info about processes that use
         the device is found by lsof(8) or fuser(1))

Achtung: Der Snapshot darf während dem FSCK nicht voll laufen. Achten Sie beim Erstellen des Snapshots daher auf eine ausreichende Dimensionierung!

Zum Erstellen des Snapshots und zum Starten des FSCK verwenden Sie folgende Kommandos:

# umount -l /dev/vg00/data
# lvcreate -s -n data_snap -L8M /dev/vg00/data
# mount /dev/vg00/data /mnt/
# lvcreate -s -n data_snap -L20G /dev/vg00/data
# fsck.ext4 -f /dev/vg00/data_snap
# lvremove -f /dev/vg00/data_snap

Der Vorteil von LVM ist, dass direkt nach dem Snapshot erstellen das Dateisystem wieder eingehängt werden kann.

Einzelnachweise

  1. 1,0 1,1 fsck routine checks on boot are disabled (launchpad.net)
  2. fstab man Page
  3. Package e2fsprogs (packages.ubuntu.com)
  4. e2fsck man Page (linux.die.net)
  5. Provide a means to query fsck whether it would run a routine check (debian.org)
Foto Christoph Mitasch.jpg

Autor: Christoph Mitasch

Christoph Mitasch arbeitet in der Abteilung Web Operations & Knowledge Transfer bei Thomas-Krenn. Er ist für die Betreuung und Weiterentwicklung der Webshop Infrastruktur zuständig. Seit einem Studienprojekt zum Thema Hochverfügbarkeit und Daten Replikation unter Linux beschäftigt er sich intensiv mit diesem Themenbereich. Nach einem Praktikum bei IBM Linz schloss er sein Diplomstudium „Computer- und Mediensicherheit“ an der FH Hagenberg ab. Er wohnt in der Nähe von Linz und ist neben der Arbeit ein begeisterter Marathon-Läufer und Jongleur, wo er mehrere Weltrekorde in der Team-Jonglage hält.


Foto Georg Schönberger.jpg

Autor: Georg Schönberger

Georg Schönberger, Abteilung DevOps bei der XORTEX eBusiness GmbH, absolvierte an der FH OÖ am Campus Hagenberg sein Studium zum Bachelor Computer- und Mediensicherheit, Studium Master Sichere Informationssysteme. Seit 2015 ist Georg bei XORTEX beschäftigt und arbeitet sehr lösungsorientiert und hat keine Angst vor schwierigen Aufgaben. Zu seinen Hobbys zählt neben Linux auch Tennis, Klettern und Reisen.


Das könnte Sie auch interessieren

Ceph
Linux Terminal Sessions mit screen im Single- und Multiuser Modus
Lsusb