login
Search
From: Miklos Szeredi <mszeredi@suse.cz>
This series addresses the problem of showing mount options in
/proc/mounts.
Several filesystems which use mount options, have not implemented a
.show_options superblock operation. Several others have implemented
this callback, but have not kept it fully up to date with the parsed
options.
Q: Why do we need correct option showing in /proc/mounts?
A: We want /proc/mounts to fully replace /etc/mtab. The reasons for
this are:
- unprivileged mounters won't be able to update /etc/mtab
- /etc/mtab doesn't work with private mount namespaces
- /etc/mtab can become out-of-sync with reality
Q: Can't this be done, so that filesystems need not bother with
implementing a .show_mounts callback, and keeping it up to date?
A: Only in some cases. Certain filesystems allow modification of a
subset of options in their remount_fs method. It is not possible
to take this into account without knowing exactly how the
filesystem handles options.
For the simple case (no remount or remount resets all options) the
patchset introduces two helpers:
generic_show_options()
save_mount_options()
These can also be used to emulate the old /etc/mtab behavior, until
proper support is added. Even if this is not 100% correct, it's still
better than showing no options at all.
The following patches fix up most in-tree filesystems, they have been
compile tested only. I would like to ask maintainers (CC-d on
respective patches) to please review, test and ACK these changes.
The following filesystems still need fixing: CIFS, NFS, XFS, Unionfs,
Reiser4. For CIFS, NFS and XFS I wasn't able to understand how some
of the options are used. The last two are not yet in mainline, so I
leave fixing those to their respective maintainers out of pure
laziness.
Table displaying status of all in-kernel filesystems:
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
legend:
none - fs has options, but doesn't ...Hi Miklos, Where did you check for the existence of a ->show_options method for unionfs? Unionfs does implement ->show_options and supports all of the mount/remount options. See: <http://git.kernel.org/?p=linux/kernel/git/ezk/unionfs.git;a=blob;f=fs/unionfs/super.c;h=986c980261a5b171147d66ac05bf08423e2fd6b6;hb=HEAD#l963> The unionfs ->remount code supports branch-management options which can add/del/change a branch, but we don't show those directly in ->show_options; it makes more sense to show the final (and thus most current) branch configuration. Could you update your records please? BTW, I should be able to use your save_mount_options(). Cheers, Erez. --
XFS has already been updated. The fix is in the XFs git tree that Andrew picks up for -mm releases and will be merged in the 2.6.25-rc1 window. Commit is here: http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/xfs-2.6.git;a=commit;h=8c33fb6ca99aa17373b... Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --
Sure. Sorry about that, I did actually look at unionfs, and it was It is probably better not to use save_mount_options(). Especially, since unionfs implemets a remount, that changes the tree only partially AFAICS. Miklos --
Hi, I asked this before and I don't remember getting an answer: How does this deal with certain special cases: - chroot: how will mount/df only show the for chroot relevant mounts? - loop: how is the connection between file and loop device maintained? I don't quite see how you want to achieve a _full_ replacement. Could also please explain why you want to go via user mounts. Other OS use a daemon for that, which e.g. can maintain access controls. How do you want to manage this? bye, Roman --
That is a very good question. Andreas Gruenbacher had some patches for fixing behavior of /proc/mounts under a chroot, but people are paranoid about userspace ABI changes (unwarranted in this case, IMO). http://lkml.org/lkml/2007/4/20/147 Anyway, if we are going to have a new 'mountinfo' file, this could be We also discussed this with Karel, maybe it didn't make it onto lkml. The proposed solution was to store the "loop" flag separately in a file under /var. It could just be an empty file for each such loop device: /var/lib/mount/loops/loop0 This file is created by mount(8) if the '-oloop' option is given. And umount(8) automatically tears down the loop device if it finds this I think a full replacement is perfectly feasible, just needs some more The unprivileged mounts patches do contain a simple form of access control. I don't think anything more is needed, but of course, having unprivileged mounts in the kernel does not prevent the use of a more sophisticated access control daemon in userspace, if that becomes necessary. Miklos --
It seems we needn't this solution. There is loop auto-destruction
patch in -mm.
Kernel part:
http://marc.info/?l=linux-kernel&m=119361296818388&w=2
mount(8) part:
http://marc.info/?l=util-linux-ng&m=119362955431694&w=2
So, with this patch mount(8) needn't to maintain info about loops and
umount(8) doesn't need to call LOOP_CLR_FD ioctl, because umount(2)
is enough.
Karel
--
Karel Zak <kzak@redhat.com>
--
Excellent! This is a very good example how moving a functionality into the kernel can greatly simplify it. Thanks, Miklos --
Hi, My question was maybe a little short. I don't doubt that we can shove a lot into the kernel, the question is rather how much of this will be A "I don't think anything more is needed" lets go off all sorts of warning lights. Most things start out simple, so IMO it's very worth it to check where it might go to to know the limits beforehand. The main question here is why should a kernel based solution be preferable over a daemon based solution? If we look for example look at OS X, it has no need for user mounts but has a daemon instead, which also provides an interesting notification system for new devices, mounts or unmount requests. All this could also be done in the kernel, but where would be the advantage in doing so? The kernel implementation would be either rather limited or only bloat the kernel. What is the feature that would make user mounts more than just a cool kernel hack? bye, Roman --
A daemon based solution would work for the "normal" case, where we have a single mount namespace and a single /etc/mtab file, and we hope it doesn't get too much out of sync with what is actually in the kernel (on remount the mount options do get out of sync, but hey, we seem to be able to live with that). However, once you start using multiple namespaces, the daemon based solution quickly becomes unusable, because you would need a separate daemon for each namespace, and it would have to somehow keep track of mount propagations in userspace (which is basically impossible), etc, etc... Does that answer your question? Thanks, Miklos --