F15: ugly behavior of "df"
Karel Zak
kzak at redhat.com
Thu Jul 21 22:39:30 UTC 2011
On Thu, Jul 21, 2011 at 01:03:52PM -0800, Jeff Spaleta wrote:
> On Thu, Jul 21, 2011 at 12:45 PM, Karel Zak <kzak at redhat.com> wrote:
> >> because
> >> really that is exactly what you want to do on your system. If our
> >> mount command will still attempt to write to /etc/mtab once its a real
> >> file again, maybe things will work for you as expected.
> >
> > No. systemd is not compatible with /etc/mtab
>
> To be clear, you are saying that systemd won't be updating /etc/mtab
> like the mount command tries to do?
https://bugzilla.redhat.com/show_bug.cgi?id=666152
(and maybe some others reports)
> Just for completely I've done some more historical searches and I'm
> seeing this argument between mtab and /proc/*/mounts going all the
> way back to 2000. And in all of the historic discussion I've seen
> relying on ./proc/*/mount has been the recommendation due to it being
> a canonical representation of what the mount points actually are at
> any given point in time.
Sure, /etc/mtab is broken by design, because
* Linux uses namespaces - you can unshare part of VFS with the rest of
the system
* only kernel has all information (typical problem is 'rw' in mtab
for read-only exported NFS)
* bind mounts are represented as /A -> /B dependence, reality is
/A -> device, /B -> device (and /A could be umounted, moved, ...)
* mount(2) is syscall, nobody is forced to use mount(8) util
* remount with options from mtab is problem if the options don't match
with real FS mount options used by kernel
* /etc/mtab~ lock is badly designed (proper fix means that you have to
fix *all* /sbin/mount.<type> helpers)
* /etc/mtab~ lock is performance problem (real issue for large
systems with autofs)
* use /etc for lock files and frequently updated files is really bad
idea (again, almost unfixable, real issue for read-only root fs)
* you need root permissions to update the file
> Do you have a complete listing somewhere of the info thekernel does
> not encode into /proc/mounts that mount has traditionally encodes into
> /etc/mtab that existing tools might be making use of?
* userspace mount(8) specific mount options (e.g. user=, uhelper=),
libmount stores these options to the *private* /run/mount/utab file.
* NFS uses also libmount to store some extra information in userspace
> I'm pretty sure based on everything I've read its not just bind
> mount info, but also perhaps user or group info concerning who has
> permission to mount and umount? Moving foward such a list would
> probably help mitigate frustration and give admins a starting point
> to adjusting their site specific configs.
I know only about the problem with 'df'.
Karel
--
Karel Zak <kzak at redhat.com>
http://karelzak.blogspot.com
More information about the devel
mailing list