fsck on boot (was: Re: Corrupted/unreadable journal: reiser vs. ext3)

[Ookhoi <ookhoi@humilis.net>]

Andreas Dilger wrote (ao):
> The other thing to keep in mind is that you can have different
> "levels" of automated fsck at boot time, depending on how long they
> take.  You never necessarily have to try and fix anything with "fsck
> -a", just detect errors and leave it up to the user to decide what to
> do if you find a problem: - always recover journal, validate
> superblock, error flag (< 1s)
> 
> Don't know how long it takes these things to run, so it is up to you
> to trade off checks vs. speed, and you could even round-robin them
> (storing the last checked item in the superblock or something):
> - check block allocation bitmaps match superblock counts
> - walk directory structure from root, checking for directory
>   corruption
> - check btree validity on inodes for up to 10 seconds (or whatever,
>   storing last checked inode in superblock for restarting this test at
>   next one)
> 
> By all means, don't do checks for an hour, or allow users to set the
> maximum boot check duration in the superblock.  I'm sure users don't
> mind waiting 5s at boot time if it means they don't lose data.

Yes! Yes! I agree so much on this .. Let fsck always run at boot, and
perform checks which take at most a few seconds all together.

Then dmesg will tell if something is wrong. Maybe it can also show the
error code in /proc/mounts ?