Based on kernel version 4.13.3. Page generated on 2017-09-23 13:55 EST.
1 Support is available for filesystems that wish to do automounting 2 support (such as kAFS which can be found in fs/afs/ and NFS in 3 fs/nfs/). This facility includes allowing in-kernel mounts to be 4 performed and mountpoint degradation to be requested. The latter can 5 also be requested by userspace. 6 7 8 ====================== 9 IN-KERNEL AUTOMOUNTING 10 ====================== 11 12 See section "Mount Traps" of Documentation/filesystems/autofs4.txt 13 14 Then from userspace, you can just do something like: 15 16 [root@andromeda root]# mount -t afs \#root.afs. /afs 17 [root@andromeda root]# ls /afs 18 asd cambridge cambridge.redhat.com grand.central.org 19 [root@andromeda root]# ls /afs/cambridge 20 afsdoc 21 [root@andromeda root]# ls /afs/cambridge/afsdoc/ 22 ChangeLog html LICENSE pdf RELNOTES-1.2.2 23 24 And then if you look in the mountpoint catalogue, you'll see something like: 25 26 [root@andromeda root]# cat /proc/mounts 27 ... 28 #root.afs. /afs afs rw 0 0 29 #root.cell. /afs/cambridge.redhat.com afs rw 0 0 30 #afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 0 31 32 33 =========================== 34 AUTOMATIC MOUNTPOINT EXPIRY 35 =========================== 36 37 Automatic expiration of mountpoints is easy, provided you've mounted the 38 mountpoint to be expired in the automounting procedure outlined separately. 39 40 To do expiration, you need to follow these steps: 41 42 (1) Create at least one list off which the vfsmounts to be expired can be 43 hung. 44 45 (2) When a new mountpoint is created in the ->d_automount method, add 46 the mnt to the list using mnt_set_expiry() 47 mnt_set_expiry(newmnt, &afs_vfsmounts); 48 49 (3) When you want mountpoints to be expired, call mark_mounts_for_expiry() 50 with a pointer to this list. This will process the list, marking every 51 vfsmount thereon for potential expiry on the next call. 52 53 If a vfsmount was already flagged for expiry, and if its usage count is 1 54 (it's only referenced by its parent vfsmount), then it will be deleted 55 from the namespace and thrown away (effectively unmounted). 56 57 It may prove simplest to simply call this at regular intervals, using 58 some sort of timed event to drive it. 59 60 The expiration flag is cleared by calls to mntput. This means that expiration 61 will only happen on the second expiration request after the last time the 62 mountpoint was accessed. 63 64 If a mountpoint is moved, it gets removed from the expiration list. If a bind 65 mount is made on an expirable mount, the new vfsmount will not be on the 66 expiration list and will not expire. 67 68 If a namespace is copied, all mountpoints contained therein will be copied, 69 and the copies of those that are on an expiration list will be added to the 70 same expiration list. 71 72 73 ======================= 74 USERSPACE DRIVEN EXPIRY 75 ======================= 76 77 As an alternative, it is possible for userspace to request expiry of any 78 mountpoint (though some will be rejected - the current process's idea of the 79 rootfs for example). It does this by passing the MNT_EXPIRE flag to 80 umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH. 81 82 If the mountpoint in question is in referenced by something other than 83 umount() or its parent mountpoint, an EBUSY error will be returned and the 84 mountpoint will not be marked for expiration or unmounted. 85 86 If the mountpoint was not already marked for expiry at that time, an EAGAIN 87 error will be given and it won't be unmounted. 88 89 Otherwise if it was already marked and it wasn't referenced, unmounting will 90 take place as usual. 91 92 Again, the expiration flag is cleared every time anything other than umount() 93 looks at a mountpoint.