2007/416 NFSv4 Mirror-mounts

[Calum Mackay]

I'm sponsoring the following fast-track for myself.

The case seeks Patch binding, for possible inclusion in an
Update release, and the interfaces described are Committed.

I have set the timer to next Wednesday, 25th July.

cheers,
calum.


			NFSv4 Mirror-mounts

This fast-track describes "mirror-mounts", a part of the NFSv4 protocol
(RFC3530) that was not included in the initial Solaris NFSv4 delivery.

Mirror-mounts enable an NFSv4 client to traverse shared filesystem mount
points in the server's NFSv4 namespace.

The main advantages over the traditional automounter-based approach are
that namespace changes on the server are immediately visible to all
clients, and there is no longer the overhead associated with
administering automount maps.

With mirror-mounts, new shared filesystems will be discovered instantly,
when the client accesses them, and automatically mounted.

Mirror-mounts are purely client-side NFSv4 behaviour, and require no new
functionality, observability, nor control, on the part of the NFSv4 server.


User visibility of mirror-mounted mount points

The sole visible difference between a mirror-mounted NFSv4 filesystem,
and a manual mount, or automount, on the NFS client, is that nfsstat(1M)
"-m" output will include an additional field "mirrormount" to note that
the mount is a mirror-mount.


Automatic unmounting

Mirror-mounted filesystems will be automatically unmounted if idle,
after a certain period of inactivity. The period will be that used by
the automounter for the same purpose, i.e. as set by the
AUTOMOUNT_TIMEOUT property in /etc/default/autofs (proposed to become
the sharectl(1M) "autofs timeout" property, see PSARC 2007/393), and
will not be separately controllable.


Recursive manual hierarchical unmounting

If an NFS filesystem is manually unmounted, then any mirror-mounted
filesystems contained within it will also be unmounted, if idle. If
there is an active mirror-mounted filesystem within, the manual unmount
will fail, as though that original filesystem were busy. A forced
unmount will, however, be propagated through to all enclosed
mirror-mounted filesystems.


Interaction with the automounter

Where there is an existing automount trigger point setup for a
particular server filesystem, it will take precedence over
mirror-mounting, i.e. a mirror-mount will not occur for that filesystem.

If a filesystem boundary is encountered within an automounted
filesystem, a mirror-mount will still occur for it. When the automounter
unmounts the parent filesystem, any mirror-mounted filesystems within it
will also be automatically unmounted, if idle. If there is an active
mirror-mounted filesystem, the automatic unmount will not occur (which
preserves current automount behaviour).


Reference

Mount Point Crossing. NFSv4 Protocol, RFC3530 Section 7.7.
     http://www.ietf.org/rfc/rfc3530.txt


Background - Existing NFSv4 server namespace browsing

     In the absence of any client automount map, the existing NFSv4
server implementation in Solaris still presents the entire server
namespace to the client, i.e server mount-points (in effect) are
visible to the client before the client has mounted them, even if the
server mount-points themselves are on a server filesystem that is not
shared:

     NFSv4-server # share
     -               /dum   rw=pawns   ""
     -               /dee   rw=pawns   ""

     # note that the server does not share "/", yet we may mount it
     NFSv4-client # mount NFSv4-server:/ /mnt
     NFSv4-client # ls -l /mnt
     total 4
     drwxr-xr-x   3 alice    pawns        512 Oct 18 15:01 dee
     drwxr-xr-x  37 root     sys         1024 Oct 18 14:50 dum

     This continues to provide the useful browsing feature, previously
available via the automounter, without imposing the overhead of a mount,
which may be important in the presence of many server filesystems e.g.
when using ZFS.

     Note that the attributes of the filesystems are presented
correctly, even thought the client has not yet mounted them, unlike the
automounter's browse feature.

     However, the contents of the server's filesystems cannot be seen:

     NFSv4-server # ls -al /dee
     total 20
     drwxr-xr-x   3 alice    pawns        512 Oct 18 15:01 .
     drwxr-xr-x  31 root     root        1024 Oct 18 15:01 ..
     drwx------   2 alice    pawns       8192 Oct 18 14:53 lost+found
     -rw-r--r--   1 alice    pawns          0 Oct 18 14:58
this_file_is_in_slash_dee

     NFSv4-client # ls -al /mnt/dee
     total 4
     drwxr-xr-x   3 alice    pawns        512 Oct 18 15:01 .
     drwxr-xr-x  31 root     root        1024 Oct 18 15:01 ..

     The proposed mirror-mount functionality would cause a real NFSv4
mount to occur when the client crosses into the new filesystem by
accessing /mnt/dee.