automount-support.txt 3.5 KB
Newer Older
1 2 3 4 5
Support is available for filesystems that wish to do automounting
support (such as kAFS which can be found in fs/afs/ and NFS in
fs/nfs/). This facility includes allowing in-kernel mounts to be
performed and mountpoint degradation to be requested. The latter can
also be requested by userspace.
Linus Torvalds's avatar
Linus Torvalds committed
6 7 8 9 10 11


See section "Mount Traps" of  Documentation/filesystems/autofs4.txt
Linus Torvalds's avatar
Linus Torvalds committed
13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

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
	[root@andromeda root]# ls /afs/cambridge
	[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/ afs rw 0 0
	#afsdoc. /afs/ afs rw 0 0


Automatic expiration of mountpoints is easy, provided you've mounted the
mountpoint to be expired in the automounting procedure outlined separately.
Linus Torvalds's avatar
Linus Torvalds committed
39 40 41

To do expiration, you need to follow these steps:

42 43
 (1) Create at least one list off which the vfsmounts to be expired can be
Linus Torvalds's avatar
Linus Torvalds committed

45 46 47
 (2) When a new mountpoint is created in the ->d_automount method, add
     the mnt to the list using mnt_set_expiry()
             mnt_set_expiry(newmnt, &afs_vfsmounts);
Linus Torvalds's avatar
Linus Torvalds committed

 (3) When you want mountpoints to be expired, call mark_mounts_for_expiry()
Linus Torvalds's avatar
Linus Torvalds committed
50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93
     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.


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.