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@xxxxxxxxxx> 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@xxxxxxxxxx> http://karelzak.blogspot.com -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
