Slashdot Mirror

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on from the daemons-that-mount-files dept.

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.

14 of 541 comments (clear)

  1. Does not replace mount by Anonymous Coward · · Score: 5, Informative

    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.

    1. Re: Does not replace mount by DrXym · · Score: 3, Informative

      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.

    2. Re: Does not replace mount by Anonymous Coward · · Score: 4, Informative

      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.

    3. Re: Does not replace mount by AmiMoJo · · Score: 1, Informative

      When it comes to security you want things that are extremely limited in functionality - that enables security to be proven and well tested. So the Unix methodology of "do one thing and do it extremely well" is a very tried and true security method.

      No, my point is that the Unix method isn't that at all. It looks superficially like it is, but actually it's all these different code bases that need checking, and which can the interact in all these different and unpredictable ways, and which are difficult to use and configure because they are not consistent with each other.

      Rather than building all the logic and actions for auto-mounting from scratch, yet more new code (even if it is just scripts) to worry about, it seems better to make use of the logic built into systemd. And the whole point of building it that way is to prevent it becoming intertwined.

      --
      const int one = 65536; (Silvermoon, Texture.cs)
      SJW, n: "Someone I don't like, and by the way I'm a fuckwit" - AC
  2. Wrapper, not replacement by Anonymous Coward · · Score: 5, Informative

    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.

  3. Re:Linux is far worse than Microsoft by Noryungi · · Score: 4, Informative

    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.

    --
    The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
  4. Devuan is a Debian distrro not shipping system d by chris2net23 · · Score: 5, Informative

    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...

  5. Re:Linux is far worse than Microsoft by Dagger2 · · Score: 5, Informative

    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.

  6. does not replace mount by JonathanP.Bennett · · Score: 4, Informative

    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.

  7. Slack Off by flyingfsck · · Score: 4, Informative

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

    --
    Excuse me, but please get off my Pennisetum Clandestinum, eh!
  8. M.C.P. by Anonymous Coward · · Score: 1, Informative

    I keep hearing about this SystemD thing. Is this the OS that Linux runs on?

    Actually, they explained what SystemD is quiet well in the precient 1982 film Tron. Except back then it was called the M.C.P. (Master Control Program) :

    I think it's about time we start calling SystemD by it proper name again: the Master Control Program.

    EOL

  9. Re: Linux is far worse than Microsoft by silentcoder · · Score: 3, Informative

    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.

    --
    Unicode killed the ASCII-art *
  10. Re:Hmmm how bad could it be? by swillden · · Score: 4, Informative

    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.

    --
    Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
  11. Re:SystemD? by Aighearach · · Score: 1, Informative

    I'm reading the comments in the linked article, and there are many good explanations of reality. The comparison here, the depth of the troll bench, it is just astounding.

    Thankfully RedHat doesn't care about loud noises from the basement. They care about money, and good software costs less to support. Which is to say that those, like RedHat, who are selling support don't have to work as hard for the same money, and the customer is happier too.

    As a service developer the network improvements are really great, I can't imagine turning my nose up at on-demand service activation. These mount improvements are right in that direction, too. I'd like to be able to have network filesystems that are only mounted if one of the services using them happens to be activated.