On Thu, 2011-01-20 at 09:55 +0100, Karel Zak wrote: > On Thu, Jan 20, 2011 at 02:08:50PM +0800, Ian Kent wrote: > > On Wed, 2011-01-19 at 18:35 +0100, Karel Zak wrote: > > > I have pushed new util-linux into rawhide. The project has been > > > renamed from util-linux-ng back to util-linux. > > > > > > The util-linux v2.19-rc1 contains support for systems without > > > /etc/mtab (the file is replaced with symlink to /proc/mounts). > > > This feature is enabled by default on Fedora (due to systemd). > > > > > > If your system depends on regular mtab then you can remove the > > > symlink -- mount(8) still supports old mtab too. > > > > Once again I say, what about mount entries that should not be reported > > against by utilities that look at the mount table? > > Ideally there is only one mount table -- in kernel. Every other mount > table sucks, because: > > - kernel supports namespaces > - everyone can call mount(2) syscall independently on mount(8) > - exclusive write access to userspace mount table is performance > problem (e.g. mtab lockig) > - mtab mount options don't match with real kernel options > - etc. > > So, our goal is to minimize number of situations where userspace > mount options are required. I'm not arguing against this at all. I'm just saying we must have a bit of co-ordination. Although I had in mind something similar to mounting an individual file rather than using a file within a file system. OTOH, it's already available for use. > > For backward compatibility and for some special cases (e.g. uhelper=, > or NFS) libmount maintains userspace mount options, but there is no > reason to care about all options for all entries. > > I hope that the user= option will be handled by kernel (by fsuid in > /proc/mounts) one day. > > The another solution is to store more information to kernel, but this > has to be individually handled by FS drivers, any generic solution > for userspace options in kernel is not planned. > > > I can tell you from experience with old versions of AIX that without > > something in the mount table to allow utilities to ignore mount entries > ^^^^^^^^^^ > What exactly? Special mount options, tags? Yeah, in Solaris all autofs mounts have a pseudo option to tell utilities not to include them in their reports. I can't remember now what it was in Solaris but it was something like "ignore". It would be easy to add an option to such mounts in the the fs super_operations .show_options method. Then no user space changes would be needed to make it appear, but then we are stuck with the "this works in kernels later than ...." problem. The crucial thing is that utilities maintainers be on board with however this is done for it to work. > > > when appropriate, as is done in Solaris, these utilities is just about > > unusable. > > findmnt(8) allows to browse mount tables (kernel, mtab, fstab). > > Now it supports select/ignore entries by FS type, mount options, > mount point (target), spec (source). Suggestions and feature requests > are welcomed. So, maybe all we really need is for utilities maintainers to use this feature. Not sure what's best and there clearly needs to be some discussion about when to leave such things as autofs file system mounts out. For example cat <whatever the mount table is> needs to always show the real contents of the mount table while calling mount(8) shouldn't. > > For example: > > $ findmnt | wc -l > 32 > > $ findmnt -t noautofs | wc -l > 27 > > Karel > -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
