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

[Chris Murphy]

On Sun, Jan 11, 2015 at 2:14 PM, Nikolai Zhubr <n-a-zhubr at 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