[Pkg-sysvinit-devel] Bug#568251: Bug#568251: Please support fsck on shutdown

[Goswin von Brederlow]

Henrique de Moraes Holschuh <hmh at debian.org> writes:

> On Fri, 05 Feb 2010, Goswin von Brederlow wrote:
>> Henrique de Moraes Holschuh <hmh at debian.org> writes:
>> > On Wed, 03 Feb 2010, Goswin von Brederlow wrote:
>> >> recently we discussed the anoyance that is fsck during boot on irc and
>> >> came to the conclusion that on many systems the shutdown would be a
>> >> btter time to do this.
>> >
>> > As long as fsck on startup remains.  We need that to avoid further damage to
>> > corrupted filesystems.
>> 
>> Obviously.
>> 
>> >> Wouldn't it be nice if during shutdown it would run fsck whenever the
>> >> next boot would do so? That way the next morning you do not have to
>> >> wait for the fsck before starting to work.
>> >
>> > Well, we do NOT have a way to tell fsck to ignore check-after-n-umounts and
>> > check-after-n-days that some filesystems implement.  The only available fix
>> > I know of is to:
>> >
>> > 1) DISABLE these misfeatures in the filesystem so that fsck won't trigger on
>> > an otherwise clean filesystem during boot
>> >
>> > 2) re-implement the check-after-whatever-trigger through a script that calls
>> > fsck -f every once in a while
>> >
>> > and we certaily could call that script on shutdown, if the user wants us to.
>> 
>> The check for this is exactly the same as during boot.
>
> Sort of.  Boot either has to check any dirty filesystems, or halt and go
> into a sulogin-or-shutdown loop.   You must NOT skip a dirty filesystem
> check at boot and continue with system startup, EVER.  We can't even offer
> that as a choice, it is known to cause worse data loss if the fs is corrupt.

I think you mean filesystem with errors instead of dirty. A dirty
ext3/4, xfs or reiserfs just needs a journal replay. Didn't think of the
error case though. Filesystems might have gotten the error bit set
during operations.

But I'm not sure that changes anything in the suggested behaviour. On
shutdown it would do the same as during boot, except prompt for the root
password. It always continous on shutdown no matter how bad the check
was.

>> > Just make triple-sure to coordinate with the UPS monitoring stuff, because
>> > if you trigger the fsck when the box is going down due to an UPS low battery
>> > shutdown, very bad things could happen.  The proper fix to that would be to
>> > add a new shutdown runlevel for the UPS stuff to use, I suppose.
>> 
>> Or laptop on battery. Same us boot there though.
>
> See above for the boot stuff.  But yes, we could/should skip gratuitous
> shutdown fscks when on battery, as they're just a convenience.
>
> Do you have any (tested) patches to propose?  The idea is sound, but the
> details on this one are really important.

Sorry no. Just the idea. Shouldn't be that hard to implement a test
though. Just cut&paste the script from startup and remove the bits that
would prompt or go into a sulogin-or-shutdown loop.

MfG
        Goswin