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.
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
