[PATCH] intrinsic automount and mountpoint degradation support
Here's a patch that I worked out with Al Viro that adds support for a
filesystem (such as kAFS) to perform automounting intrinsically without the
need for a userspace daemon. It also adds support for such mountpoints to be
degraded at the filesystem's behest until they've been untouched long enough
that they'll be removed.
I've a patch (to follow) that removes some #ifdef's from fs/afs/* thus
allowing it to make use of this facility.
There are five pieces to this:
(1) Any interested filesystem needs to have at least one list to which
expirable mountpoints can be added.
Access to this list is governed by the vfsmount_lock.
(2) When a filesystem wants to create an expirable mount, it calls
do_kern_mount() to get a handle on the filesystem it wants mounting, and
then calls do_add_mount() to mount that filesystem on the designated
mountpoint, supplying the list mentioned in (1) to which the vfsmount
will be added.
In kAFS's case, the mountpoint is a directory with a follow_link() method
defined (fs/afs/mntpt.c). This uses the struct nameidata supplied as an
argument as a determination of where the new filesystem should be
mounted.
(3) When something using a vfsmount finishes dealing with it, it calls
mntput(). This unmarks the vfsmount for immediate expiry.
There are two criteria for determining if a vfsmount may be expired - it
mustn't be marked as in use for anything other than being a child of
another vfsmount, and it must have an expiry mark against it already.
(4) The filesystem then determines the policy on expiring the mounts created
in (2). When it feels the need to, it passes the list mentioned in (1) to
mark_mounts_for_expiry() to request everything on the list be expired.
This function examines each mount listed. If the vfsmount meets the
criteria mentioned in (3), then the vfsmount is deleted from the
namespace and disposed of as for unmounting; otherwise the vfsmount is
left untouched apart from now bearing an expiration mark if it didn't
before.
kAFS's expiration policy is simply to invoke this process at regular
intervals for all the mounts on its list.
(5) An expiration facility is also provided to userspace: by calling umount()
with a MNT_EXPIRE flag, it can make a request to unmount only if the
mountpoint hasn't been used since the last request and isn't in use now.
This allows expiration to be driven by userspace instead of by the
kernel if that is desirable.
This also means that do_umount() has to use a different version of
path_release() to everyone else... it can't call mntput() as that clears
the expiration flag, thus rendering this unachievable; so it's version of
path_release() calls _mntput(), which doesn't do the clear.
My original idea was to give the kernel more knowledge of automounted
things. This avoids a certain problem with stat() on a mountpoint causing it
to mount (for example, do "ls -l /afs" on a machine with kAFS), but Al wanted
it done this way.
> Why is autofs unsuitable?
Because:
(1) Autofs is flat; AFS requires a tree - mounts on mounts on mounts on
mounts...
(2) AFS holds the data as to what the mountpoints are and where they go, and
these may be cross-links to subtrees beyond your control. It's also not
trivial to extract a list of mountpoints as is required for autofs.
(3) Autofs is not namespace safe.
(4) Ducking back to userspace to get that to do the mount is pretty tricky if
namespaces are involved.
In fact, autofs may well want to make use of this facility.
Signed-Off-By: 
David Howells <dhowells@redhat.com>
Signed-off-by: 
Andrew Morton <akpm@osdl.org>
Signed-off-by: 
Linus Torvalds <torvalds@osdl.org>
Showing
Please register or sign in to comment