[systemd-devel] Second (erroneous) check of rootfs?

[Nikolai Zhubr]

Hi,
12.01.2015 0:47, Chris Murphy:
[...]
> - man tune2fs uses very strong language to set either
> interval-between-checks or max-mount-counts. However, mke2fs 1.42.11
> (09-Jul-2014) sets neither by default. I'm not sure when this changed,
> it used to set check interval to 180, but a new file system has it set
> to 0, and max mount count to -1. So it's highly recommended but not
> the default anymore. *shrug* Not sure what to make of that.

I'd interpret this as yet another hint that e2fsck is not a tool for 
planned diagnostic. (Hence no default schedule.) Rather, it is a tool 
for (attempt of) recovery after some unexpected damage event.

That said, I do have quick fsck enabled at boot on all my machines, but 
it's more of a paranoid nature than somehow practically important.

(This is getting off-topic though, so maybe let's not abuse the mailing 
list further)


Thank you,
Nikolai

>
> - ext34, XFS, and Btrfs all do a journal replay at mount time if the
> fs was unmounted uncleanly, and normally this will fix things. If
> there are errors, mount fails. e2fsck does same check and journal
> replay if necessary that mounting does. But if that fails, e2fsck
> falls back to preening the filesystem automatically.
>
> XFS and Btrfs don't have such a fall back condition to do an automatic
> preen. For one their fsck.<foo>  does nothing successfully, those files
> don't point to the real repair utils. Their repair utils are only
> meant to be run when normal mount is tried first and then fails;
> xfs_repair will even complain if the fs hasn't been mounted first and
> tell the user to try mounting it to replay the journal since
> xfs_repair won't do that. For Btrfs, mount failure means trying
> another mount with -o recovery, not running btrfs check, which is
> almost a last resort option.
>
> I think it would be more helpful to remove the always fsck root job,
> that isn't actually doing anything 99.999% of the time. Instead, in
> case of mount failure, dracut shell should end with a cheat sheet for
> what the user ought to do to repair the file system. It knows what
> root device it is and its file system at this point so it could spit
> out the path to the repair utility, all of which now have different
> names by the way: e2fsck, xfs_repair, and for Btrfs mount -o recovery
> tried first. Right now the user is dropped into a desert, as rare as
> it is, and we ought to do better than this until we've got magical
> always self-healing file systems.
>