LWN.net Logo

Tumbleweed backs off on systemd for now

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 16:52 UTC (Tue) by jspaleta (subscriber, #50639)
In reply to: Tumbleweed backs off on systemd for now by dashesy
Parent article: Tumbleweed backs off on systemd for now

Downside in what way exactly?

There is an observable downside in terms of system performance with the use of many virtual filesystem mounts like tmpfs and cgroup mounts?

-jef


(Log in to post comments)

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 17:15 UTC (Tue) by imitev (subscriber, #60045) [Link]

mount | wc -l:

rhel5.7: 10
f15: 38

It's becoming increasingly difficult to understand mount's output, maybe that's what the OP had in mind - although it's not clear (to me) how many mounts are because of systemd only vs. how many are because of new features between rh5/f6 and f15...

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 17:43 UTC (Tue) by jspaleta (subscriber, #50639) [Link]

This is not strictly an issue with systemd.

This is a a problem that has existed for some linux users all the way back to at least 2005. If you ever wanted to run a linux system with / read only and you wanted correct mount information then you were already doing the /etc/mtab symlink trick.

For reference all the way back to 2005:
http://readlist.com/lists/vger.kernel.org/linux-kernel/25...

So Here we are in 2011, finally having to deal with the fact that the concept of a "mountable" filesystem as understood by the linux kernel has gotten much much more complex over the last several years. And that's just the beginng of the issue. You do low level valid syscalls which interact with the kernel's concept of a mount and the userspace /etc/mtab (as its controlled by the mount tool not by the kernel) goes out of sync.

This is a reality and has been a reality for years and years. Some sysadmins might not have been aware of that problem..but its been there for a long time.

And the userspace tools haven't kept up with that reality and its been known since 2005 that the existing userspace mtab was not suitable as a general solution to keeping up with mount state. systemd just makes this bloody obvious. Shoot the messenger if it makes you feel better, but don't ignore the message. The only way you can keep an accurate record of mounts is to rely on the kernel's representation of mount objects. The old /etc/mtab way does not work reliably.

So now someone gets the task of fixing the userspace tools to deal with trying to find a way to provide multiple ways to view that kernel mount information and try to hide some of the virtual filesystems like tmpfs and cgroups.

-jef

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 17:44 UTC (Tue) by vonbrand (subscriber, #4458) [Link]

On Fedora 15 I get 40 lines of output from mount(8), not counting various cgroups it's 29. And many of those are virtual filesystems that give a peek into the kernel's inards, so that depends more on the base kernel version than anything else.

In any case, what do you want to read the full output for? It is easy to check just what you need, oblivious to whatever other cruft it might spew at you. I hadn't looked at the full output for ages.

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 19:19 UTC (Tue) by imitev (subscriber, #60045) [Link]

>> "In any case, what do you want to read the full output for"

You mean filtering the output ? Reading quickly through a few short lines is easier / takes less time than thinking of a search pattern: oh, what was the fs type again ? where was it mounted ? what are the mount arguments, ...
And then: hmm, no match, did I make a mistake with the regex ? In which case it's safer to use grep -v '\(/sys\|systemd\|tmpfs\|mqueue\|hugetlbfs\)' but you'll agree it's not so convenient when you forgot to set it as an alias or you're too lazy to hack/deploy a little filtering script.

[Note: as I'm getting used to systemd - which I like - I'll just get used to have 40+ lines of mount output. I'm just outlining it used to be a bit easier before, and that for various reasons people still need to go through mount's output (I often do). As jspaleta points out user space may evolve and maybe distros will begin to ship helper scripts or patched mount...]

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 19:27 UTC (Tue) by imitev (subscriber, #60045) [Link]

>> As jspaleta points out user space may evolve and maybe distros will begin to ship helper scripts or patched mount

replying to myself: /me will have to check new commands when upgrading (thank you juergbi for the pointer to findmnt)

Tumbleweed backs off on systemd for now

Posted Sep 21, 2011 15:32 UTC (Wed) by tzafrir (subscriber, #11501) [Link]

Maybe what you actually need is df -T #?

Tumbleweed backs off on systemd for now

Posted Sep 22, 2011 3:13 UTC (Thu) by jcm (subscriber, #18262) [Link]

I get "too many lines". Too many lines is defined as more than /proc, a tmpfs or two, and my filesystems. When I have to sift through dozens of lines of useless mounts to get to the crux of what I'm using, then it's too many and it's unusable. Sure, it's not systemd's fault that mount, df, and friends don't make this easier, but it was systemd that changed the world to the point that this became a problem. As part of integration, this stuff should be addressed (and that means other than by adding a GUI for df).

Tumbleweed backs off on systemd for now

Posted Sep 20, 2011 19:16 UTC (Tue) by juergbi (subscriber, #76126) [Link]

Have you tried findmnt? Its output is much easier to read.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds