[Pkg-sysvinit-devel] IMPORTANT: issues with our filesystem check scripts

[Kel Modderman]

On Saturday 17 January 2009 06:18:50 Henrique de Moraes Holschuh wrote:
> A recent thread in debian-user by someone that had massive data loss on an
> EeePC and was blaming the initscripts for it caught my attention, and I did
> a quick check.
> 
> I found the following problems that I feel we really should address.  Please
> correct me if I am wrong:
> 
> 1. We do not honour /forcefsck properly.  IMHO, it doesn't matter if we're
> on battery, or if the moon is blue.  If /forcefsck exists, it should take
> precedence (including over /fastboot) and we should do the forced fsck on
> every filesystem, rootfs included.

Fully agreed. /forcefsck means force a fsck and that should be unconditional.

> 
> 2. We skip the rootfs check while on battery.  We really should not.  If
> even one single user gets a worse data loss than what he should have,
> because we skipped that fsck, it is already too steep a price to pay.
> 
> If someone has a big / in a laptop and fsck drains his battery dry or frags
> his patience, it is his price to pay for doing something stupid (a big
> rootfs).  I believe we should never optimize for that kind of crap over data
> safety.

I tend to agree with you, data integrity is paramount. Some people will prefer
to give priority to convenience. It will probably need to be configurable
behaviour, especially so because it would be a change in long-time default
behaviour.

> 
> Now, the really nice fix would be to teach fsck a flag to only check dirty
> filesystems, skipping the "too old", and "mounted too many times" conditions
> on filesystems that have that kind of stuff (like ext3, ext4), and use THAT
> while on battery.
> 
> Because dirty filesystems must ALWAYS be checked if you're going to mount
> them.  Any other choice is an increased chance of making a data loss
> condition worse, and that's not acceptable IMHO.
> 
> 
> So, I vote that we either remove the on_ac_power checks completely, or make
> them configurable (default disabled), while fsck is not enhanced to the
> point that it is safe to have such a test.
> 


Thanks, Kel.