F15: ugly behavior of "df"

[Karel Zak]

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