Systemd Rolls Out Its Own Mount Tool (phoronix.com)

An anonymous Slashdot reader writes: I'm surprised this hasn't surfaced on Slashdot already, but yesterday Phoronix reported that systemd will soon be handling file system mounts, along with all the other stuff that systemd has encompassed. The report generated the usual systemd arguments over on Reddit.com/r/linux with Lennart Poettering, systemd developer and architect, chiming in with a few clarifications.
Lennart argued it will greatly improve the handling of removable media like USB sticks.

Comments

Does not replace mount

[Anonymous Coward]

From Lennart's reddit comment:

"first of all, this doesn't replace util-linux' mount tool. Not at all. It just tells systemd to mount something, going through systemd's dependency logic. For the actual mount operation PID 1 will fork off util-linux' mount tool like it always did."

Big fucking deal.

Re: Does not replace mount

[DrXym]

Yes it is better as a read of the link would quickly show. It allows a user to plug in a USB stick, mount the device, mount the FS, schedule an fsck and reduce the danger if the user unplugs the stick without an explicit unmount.

Re: Does not replace mount

[Anonymous Coward]

Yes it is better as a read of the link would quickly show. It allows a user to plug in a USB stick, mount the device, mount the FS, schedule an fsck and reduce the danger if the user unplugs the stick without an explicit unmount.

Neither you, nor the link, have described anything “better” (or for that matter, “new”). It's also pretty clear that you didn't actually read the link, or you would know that very little described in the link will actually protect anyone from pulling a flash drive out before it's been cleanly unmounted. The problem with slow flash media is (and has always been) that a considerable amount of "written" data is buffered before actually being flushed out to disk. There is nothing systemd-mount can do about that. If the flash drive is no longer plugged in, you can't flush the unwritten data to it, because it's physically not there anymore. No amount of on-access fscking is going to bring that data back. What an on-access fsck will do, is try to make sure the filesystem is at least mountable. Nothing more. It doesn't decrease the danger of an unplug without unmount at all, it tries to tidy up a bit after the real damage has already been done, and does so without letting the user know the scale of the damage. Out of sight, out of mind. A very Lennart solution.

Now, take the rubbish about unsafely unplugged USB drives/on-access fsck out of the equation for a second, and what does systemd-mount actually provide? It provides better systemd integration. Nothing described in the link is unique to systemd, not even the possibility of on-access fsck. We've gone from a system where we can fully script every aspect of the start-up process, to one where you need to write code to integrate well, and half of the smaller jobs are being undertaken by the project itself because nobody can be bothered. What a gross monster we've created.

Wrapper, not replacement

[Anonymous Coward]

This is a new wrapper around the existing mount tool. Systemd is changing how it mounts things to standardize that portion of jobs, and it's also handling auto-mounting of external media, like your desktop environment probably already does. has done for ages.

Re:Linux is far worse than Microsoft

[Noryungi]

yadda yadda yadda.

Linux does not "force" you into anything: systemd is still optional and many linux distros run perfectly well without systemd (including my old friend Slackware).

And if you really don't like Linux, there is always the BSD. Nope, no systemd there, no sirree.

So anyway... yeah, you have no idea what you are talking about.

Devuan is a Debian distrro not shipping system d

[chris2net23]

Devuan is a Debian distrro not shipping system d. I only know about it because it's supported by the EOMA68 project which aims to manufacture computers based around a modular computing standard that is free software friendly. Unlike Intel/AMD: https://www.crowdsupply.com/eo...

Re:Linux is far worse than Microsoft

[Dagger2]

Realistically, the Linux ecosystem forces you to pick between running a minor distro that you don't want to use, running a major distro with systemd removed (with broken functionality) or giving up and using systemd.

I suppose you could technically call that "not forcing" on the basis that you made the choice to use Linux in the first place, but... nope. Still being forced.

does not replace mount

[JonathanP.Bennett]

When I first read this on Phoronix, it appeared that systemd was replacing the mount command. This is not the case. It is wrapping the mount command. That seems to be an important distinction. Replacing mount would be crazy and pointless. Handling mounts more intelligently during startup would be welcome. So far, this seems to be the latter instead of the former.

Slack Off

[flyingfsck]

I use Slackware, so I don't need to know what it is all about. Thanks Pat!

Re: Linux is far worse than Microsoft

[silentcoder]

You clearly have no idea what a strawman argument even is. You took the adoption of systemD by distro maintainers and made a claim (with no evidence) to explain it.
I merely pointed out how meaningless your claim is.
I didnt misrepresent your argument by focussing on a tiny bit of it. I addressed everything you said.
Its not a strawman when your argument really was that weak.

Re:Hmmm how bad could it be?

[swillden]

Systemd-logind must be restarted every ~1000 SSH logins to prevent a ~25s delay

https://bugs.launchpad.net/ubu...

Except... it wasn't a systemd bug at all. Per comment #16:

Ok, with everyone confirming that the systemd patch is not required, I am closing the systemd part of the bug as 'Invalid' - let's only concentrate on the dbus part here. That being said, I would not like to release a new patch for dbus downstream if the patch hasn't been fully reviewed and approved upstream. In this case I would propose to wait a bit and see if a finalized patch will be available.

Not that the presence of one bug in systemd would indicate that the whole approach is a bad idea... but it's rather funny that the one example you pick turns out not to be a systemd bug at all.