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

[Chris Murphy]

On Sun, Jan 11, 2015 at 4:48 AM, Nikolai Zhubr <n-a-zhubr at yandex.ru> wrote:
> Hi,
> 11.01.2015 1:31, Chris Murphy:
>>
>> Yeah it's a bit messy and I really think to some degree this should be
>> bounced back to the ext developers and say "how do you envision this
>> working" because doing the right thing for ext4 really burdens
>> multiple other processes: systemd of course, but also dracut, and then
>> linux-utils is pulled in since that's where generic fsck is, which
>> then calls e2fsck. It's at this point really overly complicated.
>
>
> IMO there is nothing wrong with ext4 itself. It is relaible and simple. It
> does not tend to break spontaneously, or because mount-count reached some
> higher number, or because of extended periods of uptime, or even because of
> abrupt power-off. It only breaks when something _external_ really hurts it,
> like failed hardware, failed raid, mad user, or some invalid fsck.
>
> 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?

That's all I meant by bouncing back to ext devs. I don't mean there's
anything wrong with ext4. It's pretty clear the XFS and Btrfs devs
expect that if a normal rw mount fails, that boot fails and we're
dropped to a dracut shell with an unmounted root. And hopefully our fs
repair tool is in the initramfs so we can run it on the unmounted
root. Is that good enough for ext4 also? Or do they still really want
e2fsck run every boot?

It just seems there's a more elegant way to do this. Wasn't there some
big blow up recently, where some people were mad they couldn't cancel
these lengthy e2fsck's on ext4 volumes? Seems like a bad idea to
cancel an in-progress fsck anyway, but it had been scheduled 180 days
prior as the mkfs default. There was already tacit permission to do
this full fsck. However, a vastly better UX would be to communicate
the need to do this differently, like a notification that says "a full
fsck is recommended on the next boot, set this now?"



-- 
Chris Murphy