[systemd-devel] fsckd needs to go -- possible compromise?

[Kay Sievers]

On Wed, Apr 8, 2015 at 4:18 PM, Martin Pitt <martin.pitt at ubuntu.com> wrote:
> Lennart Poettering [2015-04-07 16:14 +0200]:
>> Well, the asnc IO socket handling thing was not dealt with. The newest
>> patches still use fgets().
>> [...]
>> The killer issue really is the safety issue. We shouldn't include
>> code in systemd that makes dangerous things like killing running
>> fscks an easily accessible operation, that has a graphical UI and
>> requires no authentication.
>
> So, would you reconsider your position if we address the two things
> above? I. e. replace fgets() by our own async buffering, and entirely
> remove the cancel support? Then we'd still get a proper feedback
> during boot instead of leaving the user in the dark why booting is
> stuck, but it stays noninteractive.

I don't think there is enough justification for a fsck daemon. Large
filesystems which need fsck in userspace are a thing from the past and
insufficiently developed technology for today's operating system
tasks. Basic filesystem consistency and maintenance tasks belong into
the kernel and nowhere else.

We made it just fine into the year 2015 with the support for the
legacy filesystems, and we did not need a specialized daemon so far.
Therefore, we can except that the current level of support will be
sufficient for the coming years. We will support them well enough
until everybody will finally realize that they do not solve the
problems we face today, and that they need to be replaced.

Please keep things like fsckd in the distribution that wants to make
such promises about legacy technology. Systemd upstream should focus
on current and future technologies and not pimp up outdated
facilities, waste our time and and add more complex logic and rules in
the basic boot process.

Thanks,
Kay