shutdown und e2fsck

02/06/2008 - 19:09 von Hans-Joachim Zierke | Report spam
Hi,

mein Debian Stable pflegte nach einem Reboot, so der Mount Count einer
Platte überschritten war, einen Check durchzuführen.

Seit irgendeinem Sicherheitsupdate ist das nicht mehr so, sondern
Herr/Frau Linux empfiehlt nur noch, e2fsck aufzurufen. Das mag
prinzipiell die bessere Lösung sein, sofern man das alte Verhalten
manuell wiederherstellen kann.

Ich habe nun "man reboot" und "man shutdown" befragt, finde aber nur,
als Optionen zu shutdown, -f und -F, um es entweder zu erzwingen oder
bleibenzulassen.

Gibt es noch irgendeine geheime Option, um nur die Platten mit zu hohem
Mountcount zu checken?


Hans-Joachim


Busy in a narrow valley:

http://www.railpictures.net/images/...306000.jpg
 

Lesen sie die antworten

#1 Marc Stürmer
02/06/2008 - 21:03 | Warnen spam
Hans-Joachim Zierke wrote:

Gibt es noch irgendeine geheime Option, um nur die Platten mit zu hohem
Mountcount zu checken?



Richtiger Gedankengang, aber falsche Ecke an der du suchst.

Generell solltest du dir /etc/fstab mal ansehen, genauer die 6. Spalte, die
den Parameter fs_passno an fsck übergibt.

Weiterhin empfiehlt sich noch tune2fs bei ext2/ext3 mit dem Parameter -c,
evtl. noch zusàtzlich -i.

Man sagt dazu:

-c max-mount-counts
Adjust the number of mounts after which the filesystem will be
checked by e2fsck(8). If max-mount-counts is 0 or -1, the num-
ber of times the filesystem is mounted will be disregarded by
e2fsck(8) and the kernel.

Staggering the mount-counts at which filesystems are forcibly
checked will avoid all filesystems being checked at one time
when using journaled filesystems.

You should strongly consider the consequences of disabling
mount-count-dependent checking entirely. Bad disk drives,
cables, memory, and kernel bugs could all corrupt a filesystem
without marking the filesystem dirty or in error. If you are
using journaling on your filesystem, your filesystem will never
be marked dirty, so it will not normally be checked. A filesys-
tem error detected by the kernel will still force an fsck on the
next reboot, but it may already be too late to prevent data loss
at that point.

See also the -i option for time-dependent checking.

Ähnliche fragen