[systemd-devel] fsckd needs to go

[Lennart Poettering]

B1;3802;0cOn Fri, 03.04.15 15:17, Didier Roche (didrocks at ubuntu.com) wrote:

> >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...
>
> I misunderstood first what you wanted in 2011, reading back from the mailing
> list. You would have noted that no comment (even on the first review which
> were made) raised those points in the multiple reviews that occured, hence
> it was merged. It's weird that it doesn't even boot your own machine
> reliably, as we have the first implementation running on all vivid machines
> by default, and it seems from the bug reports, reliably.

It might have to do with the fact that our ply set up (with themes,
...) is different than Ubuntu's.

> However, I'm a bit surprised about the statement that no attempt has been
> done to fix it. I think you saw I have always been responsive, prioritizing
> your suggestions over other work to fix them. When you did your first public
> personal reserves about fsckd on the mainling list and I understood what
> flow you wanted[1], I posted fixes *the day after* (with some back and force
> review) to address your comments.

I reviewed some of the initial patches, but please note that it was
merged by Pitti before I had a final look on it.

Well, the major problem (with the socket handling) are completely
unfixed still, and no patch has been posted afaics that fixed that.

I am aware that we didn't communicate this all properly, but Kay,
Daniel, David and I only sat down the day before yesterday to come to
a conclusion about all of this.

> All of them were merged by other systemd hackers and some even by ourself,
> but the biggest one, which directly addressed and implemented the flow of
> data you explicitly asked for is still waiting:
> http://lists.freedesktop.org/archives/systemd-devel/2015-March/029309.html
> (Note that this was proposed less than 48 hours after your complain about
> the data flow). Knowing that you were on holidays, I didn't push others too
> much, but Martin and I pinged you on IRC about it when you were back. Am I
> missing anything?

Well, I had a brief look at this patch, but it still doesn't get the
socket IO stuff right. It uses synchronous fgets() to read things of
the sockets, that's still not OK, and is a major thing that is
wrong. by looking at the patch I am pretty sure this all will lock up
if you have multiple fsck, to the point where you cause all fscks to
stop but the first one until the first once is finished, and so
on... (I does remove the extra bumping off systemd-fsckd though,
that's good!)

> >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
> >why such functionality never existed on Fedora or RHEL: it's risky. I
> >mean, it's all good allowing people to shoot themselves in the foot,
> >but there's really *no* point in making that easy and giving it a
> >fancy UI with support in the graphical boot splash. Shooting yourself
> >in the foot should be possible, but not *easily*! And certainly not be
> >allowed without prior authentication like you are doing it right now
> >with the plymouth support.
>
> I can understand those points, just a little bit disappointed that wasn't
> stated months ago, when we started to work on it and before the whole
> refactoring…

Yes, sorry for that. We should have sat down earlier, and come to a
conclusion about this. 

Sorry for the unclear message we were sending!

Lennart

-- 
Lennart Poettering, Red Hat