1Support is available for filesystems that wish to do automounting support (such
  2as kAFS which can be found in fs/afs/). This facility includes allowing
  3in-kernel mounts to be performed and mountpoint degradation to be
  4requested. The latter can also be requested by userspace.
 
  5
  6
  7======================
  8IN-KERNEL AUTOMOUNTING
  9======================
 10
 11A filesystem can now mount another filesystem on one of its directories by the
 12following procedure:
 13
 14 (1) Give the directory a follow_link() operation.
 15
 16     When the directory is accessed, the follow_link op will be called, and
 17     it will be provided with the location of the mountpoint in the nameidata
 18     structure (vfsmount and dentry).
 19
 20 (2) Have the follow_link() op do the following steps:
 21
 22     (a) Call vfs_kern_mount() to call the appropriate filesystem to set up a
 23         superblock and gain a vfsmount structure representing it.
 24
 25     (b) Copy the nameidata provided as an argument and substitute the dentry
 26	 argument into it the copy.
 27
 28     (c) Call do_add_mount() to install the new vfsmount into the namespace's
 29	 mountpoint tree, thus making it accessible to userspace. Use the
 30	 nameidata set up in (b) as the destination.
 31
 32	 If the mountpoint will be automatically expired, then do_add_mount()
 33	 should also be given the location of an expiration list (see further
 34	 down).
 35
 36     (d) Release the path in the nameidata argument and substitute in the new
 37	 vfsmount and its root dentry. The ref counts on these will need
 38	 incrementing.
 39
 40Then from userspace, you can just do something like:
 41
 42	[root@andromeda root]# mount -t afs \#root.afs. /afs
 43	[root@andromeda root]# ls /afs
 44	asd  cambridge  cambridge.redhat.com  grand.central.org
 45	[root@andromeda root]# ls /afs/cambridge
 46	afsdoc
 47	[root@andromeda root]# ls /afs/cambridge/afsdoc/
 48	ChangeLog  html  LICENSE  pdf  RELNOTES-1.2.2
 49
 50And then if you look in the mountpoint catalogue, you'll see something like:
 51
 52	[root@andromeda root]# cat /proc/mounts
 53	...
 54	#root.afs. /afs afs rw 0 0
 55	#root.cell. /afs/cambridge.redhat.com afs rw 0 0
 56	#afsdoc. /afs/cambridge.redhat.com/afsdoc afs rw 0 0
 57
 58
 59===========================
 60AUTOMATIC MOUNTPOINT EXPIRY
 61===========================
 62
 63Automatic expiration of mountpoints is easy, provided you've mounted the
 64mountpoint to be expired in the automounting procedure outlined above.
 65
 66To do expiration, you need to follow these steps:
 67
 68 (3) Create at least one list off which the vfsmounts to be expired can be
 69     hung. Access to this list will be governed by the vfsmount_lock.
 70
 71 (4) In step (2c) above, the call to do_add_mount() should be provided with a
 72     pointer to this list. It will hang the vfsmount off of it if it succeeds.
 
 73
 74 (5) When you want mountpoints to be expired, call mark_mounts_for_expiry()
 75     with a pointer to this list. This will process the list, marking every
 76     vfsmount thereon for potential expiry on the next call.
 77
 78     If a vfsmount was already flagged for expiry, and if its usage count is 1
 79     (it's only referenced by its parent vfsmount), then it will be deleted
 80     from the namespace and thrown away (effectively unmounted).
 81
 82     It may prove simplest to simply call this at regular intervals, using
 83     some sort of timed event to drive it.
 84
 85The expiration flag is cleared by calls to mntput. This means that expiration
 86will only happen on the second expiration request after the last time the
 87mountpoint was accessed.
 88
 89If a mountpoint is moved, it gets removed from the expiration list. If a bind
 90mount is made on an expirable mount, the new vfsmount will not be on the
 91expiration list and will not expire.
 92
 93If a namespace is copied, all mountpoints contained therein will be copied,
 94and the copies of those that are on an expiration list will be added to the
 95same expiration list.
 96
 97
 98=======================
 99USERSPACE DRIVEN EXPIRY
100=======================
101
102As an alternative, it is possible for userspace to request expiry of any
103mountpoint (though some will be rejected - the current process's idea of the
104rootfs for example). It does this by passing the MNT_EXPIRE flag to
105umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH.
106
107If the mountpoint in question is in referenced by something other than
108umount() or its parent mountpoint, an EBUSY error will be returned and the
109mountpoint will not be marked for expiration or unmounted.
110
111If the mountpoint was not already marked for expiry at that time, an EAGAIN
112error will be given and it won't be unmounted.
113
114Otherwise if it was already marked and it wasn't referenced, unmounting will
115take place as usual.
116
117Again, the expiration flag is cleared every time anything other than umount()
118looks at a mountpoint.

 1Support is available for filesystems that wish to do automounting
 2support (such as kAFS which can be found in fs/afs/ and NFS in
 3fs/nfs/). This facility includes allowing in-kernel mounts to be
 4performed and mountpoint degradation to be requested. The latter can
 5also be requested by userspace.
 6
 7
 8======================
 9IN-KERNEL AUTOMOUNTING
10======================
11
12See section "Mount Traps" of  Documentation/filesystems/autofs4.txt
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
13
14Then 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
24And 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===========================
34AUTOMATIC MOUNTPOINT EXPIRY
35===========================
36
37Automatic expiration of mountpoints is easy, provided you've mounted the
38mountpoint to be expired in the automounting procedure outlined separately.
39
40To 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
60The expiration flag is cleared by calls to mntput. This means that expiration
61will only happen on the second expiration request after the last time the
62mountpoint was accessed.
63
64If a mountpoint is moved, it gets removed from the expiration list. If a bind
65mount is made on an expirable mount, the new vfsmount will not be on the
66expiration list and will not expire.
67
68If a namespace is copied, all mountpoints contained therein will be copied,
69and the copies of those that are on an expiration list will be added to the
70same expiration list.
71
72
73=======================
74USERSPACE DRIVEN EXPIRY
75=======================
76
77As an alternative, it is possible for userspace to request expiry of any
78mountpoint (though some will be rejected - the current process's idea of the
79rootfs for example). It does this by passing the MNT_EXPIRE flag to
80umount(). This flag is considered incompatible with MNT_FORCE and MNT_DETACH.
81
82If the mountpoint in question is in referenced by something other than
83umount() or its parent mountpoint, an EBUSY error will be returned and the
84mountpoint will not be marked for expiration or unmounted.
85
86If the mountpoint was not already marked for expiry at that time, an EAGAIN
87error will be given and it won't be unmounted.
88
89Otherwise if it was already marked and it wasn't referenced, unmounting will
90take place as usual.
91
92Again, the expiration flag is cleared every time anything other than umount()
93looks at a mountpoint.