On Sun, Jan 11, 2015 at 2:14 PM, Nikolai Zhubr <n-a-zh...@yandex.ru> wrote: > Hi, > 11.01.2015 23:03, Reindl Harald: >> >> >> Am 11.01.2015 um 12:48 schrieb Nikolai Zhubr: >>> >>> I suppose this traditional (historical) technique of maintaining >>> mount-count, running fsck at boot time before remount r/w, etc, should >>> not be so much attributed specifically to ext filesystem. Most probably >>> it existed long before even ext2 appeared. However, 15 years ago I was >>> already wondering about the motivation of running full fsck depending of >>> mount-count. What's the point really? >> >> >> because you get aware of problems > > > I fully agree thay getting aware is good, but... > >> real story shortly before christmas: reboot of our fileserver running on >> the same virtualization cluster and SAN storage as other servers, mount >> count reached -> emergency shell, manual fsck and confirm all things to >> fix >> >> i really do not want to know what would have happened a year later with >> the filesystem, after that i rebooted all other servers with a forced >> fsck and not a single one while sharing the same hardware had an error > > > ... I'm not quite sure e2fsck is an appropriate and reliable tool for > storage media diagnostics and fault monitoring. How much time would you like > to wait before you get aware your data is lost?
- 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. - 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. -- Chris Murphy _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
