1f5ce9e93a
Replace all module uses with the new vfs_kern_mount() interface, and fix up simple_pin_fs(). Signed-off-by: Trond Myklebust <Trond.Myklebust@netapp.com>
119 lines
4.6 KiB
Plaintext
119 lines
4.6 KiB
Plaintext
Support is available for filesystems that wish to do automounting support (such
|
|
as kAFS which can be found in fs/afs/). This facility includes allowing
|
|
in-kernel mounts to be performed and mountpoint degradation to be
|
|
requested. The latter can also be requested by userspace.
|
|
|
|
|
|
======================
|
|
IN-KERNEL AUTOMOUNTING
|
|
======================
|
|
|
|
A filesystem can now mount another filesystem on one of its directories by the
|
|
following procedure:
|
|
|
|
(1) Give the directory a follow_link() operation.
|
|
|
|
When the directory is accessed, the follow_link op will be called, and
|
|
it will be provided with the location of the mountpoint in the nameidata
|
|
structure (vfsmount and dentry).
|
|
|
|
(2) Have the follow_link() op do the following steps:
|
|
|
|
(a) Call vfs_kern_mount() to call the appropriate filesystem to set up a
|
|
superblock and gain a vfsmount structure representing it.
|
|
|
|
(b) Copy the nameidata provided as an argument and substitute the dentry
|
|
argument into it the copy.
|
|
|
|
(c) Call do_add_mount() to install the new vfsmount into the namespace's
|
|
mountpoint tree, thus making it accessible to userspace. Use the
|
|
nameidata set up in (b) as the destination.
|
|
|
|
If the mountpoint will be automatically expired, then do_add_mount()
|
|
should also be given the location of an expiration list (see further
|
|
down).
|
|
|
|
(d) Release the path in the nameidata argument and substitute in the new
|
|
vfsmount and its root dentry. The ref counts on these will need
|
|
incrementing.
|
|
|
|
Then from userspace, you can just do something like:
|
|
|
|
[root@andromeda root]# mount -t afs \#root.afs. /afs
|
|
[root@andromeda root]# ls /afs
|
|
asd cambridge cambridge.redhat.com grand.central.org
|
|
[root@andromeda root]# ls /afs/cambridge
|
|
afsdoc
|
|
[root@andromeda root]# ls /afs/cambridge/afsdoc/
|
|
ChangeLog html LICENSE pdf RELNOTES-1.2.2
|
|
|
|
And then if you look in the mountpoint catalogue, you'll see something like:
|
|
|
|
[root@andromeda root]# cat /proc/mounts
|
|
...
|
|
#root.afs. /afs afs rw 0 0
|
|
#root.cell. /afs/cambridge.redhat.com afs rw 0 0
|
|
#afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 0
|
|
|
|
|
|
===========================
|
|
AUTOMATIC MOUNTPOINT EXPIRY
|
|
===========================
|
|
|
|
Automatic expiration of mountpoints is easy, provided you've mounted the
|
|
mountpoint to be expired in the automounting procedure outlined above.
|
|
|
|
To do expiration, you need to follow these steps:
|
|
|
|
(3) Create at least one list off which the vfsmounts to be expired can be
|
|
hung. Access to this list will be governed by the vfsmount_lock.
|
|
|
|
(4) In step (2c) above, the call to do_add_mount() should be provided with a
|
|
pointer to this list. It will hang the vfsmount off of it if it succeeds.
|
|
|
|
(5) When you want mountpoints to be expired, call mark_mounts_for_expiry()
|
|
with a pointer to this list. This will process the list, marking every
|
|
vfsmount thereon for potential expiry on the next call.
|
|
|
|
If a vfsmount was already flagged for expiry, and if its usage count is 1
|
|
(it's only referenced by its parent vfsmount), then it will be deleted
|
|
from the namespace and thrown away (effectively unmounted).
|
|
|
|
It may prove simplest to simply call this at regular intervals, using
|
|
some sort of timed event to drive it.
|
|
|
|
The expiration flag is cleared by calls to mntput. This means that expiration
|
|
will only happen on the second expiration request after the last time the
|
|
mountpoint was accessed.
|
|
|
|
If a mountpoint is moved, it gets removed from the expiration list. If a bind
|
|
mount is made on an expirable mount, the new vfsmount will not be on the
|
|
expiration list and will not expire.
|
|
|
|
If a namespace is copied, all mountpoints contained therein will be copied,
|
|
and the copies of those that are on an expiration list will be added to the
|
|
same expiration list.
|
|
|
|
|
|
=======================
|
|
USERSPACE DRIVEN EXPIRY
|
|
=======================
|
|
|
|
As an alternative, it is possible for userspace to request expiry of any
|
|
mountpoint (though some will be rejected - the current process's idea of the
|
|
rootfs for example). It does this by passing the MNT_EXPIRE flag to
|
|
umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH.
|
|
|
|
If the mountpoint in question is in referenced by something other than
|
|
umount() or its parent mountpoint, an EBUSY error will be returned and the
|
|
mountpoint will not be marked for expiration or unmounted.
|
|
|
|
If the mountpoint was not already marked for expiry at that time, an EAGAIN
|
|
error will be given and it won't be unmounted.
|
|
|
|
Otherwise if it was already marked and it wasn't referenced, unmounting will
|
|
take place as usual.
|
|
|
|
Again, the expiration flag is cleared every time anything other than umount()
|
|
looks at a mountpoint.
|