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

[Goswin von Brederlow]

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

> On Wed, 10 Feb 2010, Goswin von Brederlow wrote:
>> The suggestion here is far simpler. Just do it on boot like now and on
>> shutdown without ever blocking. That would mean that on boot under
>
> What stops the time-based trigger from not being active when the shutdown
> would fsck, but becoming active in the next boot?

Nothing. If you happen to shut down just before the time lapses and boot
after then you have bad luck. But what is the probability that you will
reboot just then?

My use case was for systems that get shut down every night so the
trigger is the number of mounts every time.

> A simple call to fsck after umounting filesystems would avoid triggering the
> max-mounts-since-last-fsck trigger on boot for everything but the root
> filesystem (which we can't umount), but fixing the two remaining boundary
> conditions ain't that easy (rootfs, and time-based fsck triggers).

It would also trigger if you shutdown after the been-too-long time. I
would think that systems that run that long without shutdown are
unlikely to be down long and unlikely to be down just at the wrong
time. If it avoids 99% of all fsck at boot that is a huge success.

> With some testing, maybe we can fsck the root on shutdown *when* we succeed
> at remounting it read-only (but we have to make sure the behaviour, should

Do we ever fail to remount RO?

If remounting RO isn't enough one could load a ramdisk and pivot_root to
that for the final fsck. That would involve a lot more work though.

> fsck find any errors, will be sane.  And that does mean not changing a power
> off into a reboot, etc).  For time-based triggers, the only fix I can think
> of is to disable them in the filesystem itself.

No. If it finds any errors then it must not flag the filesystem as
checked and power off. Then on boot it will do the normal check and
prompt for the root password. This is ment so that one can type "halt"
and still walk away with the ensurance that the system will power off on
its own.

> Note that I am not against a partial fix at all, send the patches in :-)
> But it would be nice if we would change the installer and mkfs defaults to
> avoid enabling any time-based triggers by default.

I don't think time-based triggers are a waste. The bits on the medium
degrade over time and the errors build up till the ECC can't correct
them anymore. By reading the metadata every now and then you give the
drive a chance to detect degraded blocks and rewrite them before the
errors become uncorrectable. You also detect when blocks do become
uncorrectable.

The perfect solution would be to do online fsck. But till then time and
count based triggers are the safest way.

MfG
        Goswin