Re: fsck na boot afbreken
On Sat, Aug 20, 2011 at 09:52:42PM +0200, Paul van der Vlis wrote:
> Op 20-08-11 20:56, Geert Stappers schreef:
> > On Sat, Aug 20, 2011 at 08:17:58PM +0200, Paul van der Vlis wrote:
> >>
> >> Is er ook een mogelijkheid om een fsck vlak na de reboot af te breken en
> >> gewoon te booten? Het gaat om een systeem met Lenny.
> >>
> >> Achtergrond: het systeem heeft problemen met zijn hardware klok.
> >> Hierdoor wil het steeds weer fsck uitvoeren na het booten, onder
> >> vermelding dat het systeem al jaren niet gecheckt is.
> >>
> >> Overigens ben ik ook nieuwsgierig naar oplossingen voor Squeeze, mocht
> >> dat anders zijn. Soms komt een fsck gewoon niet goed uit.
> >
> > Als een hardware klok het probleem is,
> > dan zal daar ook de oplossing zijn.
>
> Ja, alleen moet je wel elke keer heeeeel lang wachten tot de check klaar
> is als het nog niet goed is. En het is nog niet helemaal zeker wat er
> aan de hand is. Ik ga er juist naar toe om dat uit te zoeken.
>
> > Of een file system check af te breken is? Ik weet het niet.
> > Misschien kan, maar je moet het niet willen.
> >
>
> Het gaat om zo'n check die komt als je filesysteem 180 dagen niet
> gecheckt is, of na 36 mounts.
>
> In mijn geval is het filesysteem niet rot, er is alleen iets mis met de
> tijd, waardoor hij denkt dat het systeem al lang niet gecheckt is.
Uit de manual page van tune2fs
OPTIONS
-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.
Groeten
Geert Stappers
--
> And is there a policy on top-posting vs. bottom-posting?
Yes.
Reply to: