99 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3=================4Automount Support5=================6 7 8Support is available for filesystems that wish to do automounting9support (such as kAFS which can be found in fs/afs/ and NFS in10fs/nfs/). This facility includes allowing in-kernel mounts to be11performed and mountpoint degradation to be requested. The latter can12also be requested by userspace.13 14 15In-Kernel Automounting16======================17 18See section "Mount Traps" of Documentation/filesystems/autofs.rst19 20Then from userspace, you can just do something like::21 22 [root@andromeda root]# mount -t afs \#root.afs. /afs23 [root@andromeda root]# ls /afs24 asd cambridge cambridge.redhat.com grand.central.org25 [root@andromeda root]# ls /afs/cambridge26 afsdoc27 [root@andromeda root]# ls /afs/cambridge/afsdoc/28 ChangeLog html LICENSE pdf RELNOTES-1.2.229 30And then if you look in the mountpoint catalogue, you'll see something like::31 32 [root@andromeda root]# cat /proc/mounts33 ...34 #root.afs. /afs afs rw 0 035 #root.cell. /afs/cambridge.redhat.com afs rw 0 036 #afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 037 38 39Automatic Mountpoint Expiry40===========================41 42Automatic expiration of mountpoints is easy, provided you've mounted the43mountpoint to be expired in the automounting procedure outlined separately.44 45To do expiration, you need to follow these steps:46 47 (1) Create at least one list off which the vfsmounts to be expired can be48 hung.49 50 (2) When a new mountpoint is created in the ->d_automount method, add51 the mnt to the list using mnt_set_expiry()::52 53 mnt_set_expiry(newmnt, &afs_vfsmounts);54 55 (3) When you want mountpoints to be expired, call mark_mounts_for_expiry()56 with a pointer to this list. This will process the list, marking every57 vfsmount thereon for potential expiry on the next call.58 59 If a vfsmount was already flagged for expiry, and if its usage count is 160 (it's only referenced by its parent vfsmount), then it will be deleted61 from the namespace and thrown away (effectively unmounted).62 63 It may prove simplest to simply call this at regular intervals, using64 some sort of timed event to drive it.65 66The expiration flag is cleared by calls to mntput. This means that expiration67will only happen on the second expiration request after the last time the68mountpoint was accessed.69 70If a mountpoint is moved, it gets removed from the expiration list. If a bind71mount is made on an expirable mount, the new vfsmount will not be on the72expiration list and will not expire.73 74If a namespace is copied, all mountpoints contained therein will be copied,75and the copies of those that are on an expiration list will be added to the76same expiration list.77 78 79Userspace Driven Expiry80=======================81 82As an alternative, it is possible for userspace to request expiry of any83mountpoint (though some will be rejected - the current process's idea of the84rootfs for example). It does this by passing the MNT_EXPIRE flag to85umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH.86 87If the mountpoint in question is in referenced by something other than88umount() or its parent mountpoint, an EBUSY error will be returned and the89mountpoint will not be marked for expiration or unmounted.90 91If the mountpoint was not already marked for expiry at that time, an EAGAIN92error will be given and it won't be unmounted.93 94Otherwise if it was already marked and it wasn't referenced, unmounting will95take place as usual.96 97Again, the expiration flag is cleared every time anything other than umount()98looks at a mountpoint.99