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