[systemd-devel] fsckd needs to go

[Lennart Poettering]

On Tue, 07.04.15 18:02, Dimitri John Ledkov (dimitri.j.ledkov at intel.com) wrote:

> On 3 April 2015 at 05:58, Lennart Poettering <lennart at poettering.net> wrote:
> > Heya,
> >
> > so we discussed the whole fsckd situation a bit more here in Berlin,
> > and we came to the conclusion that fsckd really should not exist the
> > way it does in systemd.
> >
> > To start with, the code is really wrong, it should never have been
> > merged in its current state, the read/write logic for the sockets is
> > completely borked (I cannot even boot my own machine reliably with
> > it!). And to my knowledge there has been no attempt to fix all of
> > that, even though I asked for it. It also doesn't do at all what I
> > suggested initially, as the flow of data is now fsck → systemd-fsck →
> > systemd-fsckd → plymouth, and that's just crazy, that's two steps too
> > many. systemd is supposed to be a few components playing well
> > together, but certainly not a baroque network of components where data
> > is passed though four hoops before it reaches the destination...
> >
> > Then, there's my general reservation with fsckd at all: file systems
> > that still require offline fsck are certainly not the future, but we
> > develop stuff for the future, and the idea to kill an fsck process
> > while it is running is also very very questionnable. There's a reason
> 
> Is this about progress & control data or all things fsck?

Well, ext234 require fsck, there's no way around it. We need to call
it, and we will. But the idea of beefing this up with an UI and
specifically with an unauthenticated way to kill fsck while it is
ongoing, which is an inherently unsafe operation, is what I have
issues with.

> IMHO we do need to continue support ext4, and running fsck.ext4 when
> enforced, at least from initramfs, with progress output to the user
> and ability to cancel. Or is even fsck.ext4 obsolete these days and
> shouldn't be run automatically any more?

Nope. ext2, ext3, ext4, fat require an fsck tool to be run, and we
will.

Lennart

-- 
Lennart Poettering, Red Hat