diff options
Diffstat (limited to 'Documentation/filesystems/automount-support.txt')
| -rw-r--r-- | Documentation/filesystems/automount-support.txt | 118 |
1 files changed, 0 insertions, 118 deletions
diff --git a/Documentation/filesystems/automount-support.txt b/Documentation/filesystems/automount-support.txt deleted file mode 100644 index 7cac200e2a85..000000000000 --- a/Documentation/filesystems/automount-support.txt +++ /dev/null @@ -1,118 +0,0 @@ -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. |