Mirror-mounts will enable an NFSv4 client to traverse shared filesystem mount points in the server namespace.This enables a move away from arbitrary filesystem boundaries, towards a global namespace, and, eventually, to remove the requirement for the MOUNT protocol for v4-only mounts.
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.
As an example, consider the case where a system administrator is migrating from a single, large, UFS filesystem, to many small ZFS filesystems. With an existing automounter-based setup, the new ZFS shared filesystems will need to be individually listed in indirect automount maps. Depending on the type of naming service in use, and its update schedule, these changes might take a considerable amount of time to be seen by all clients.
In contrast, with mirror-mounts, the new shared filesystems will be discovered instantly, when the client accesses them, and automatically mounted.
NOTE: Mirror-mounts are an NFS client enhancement based upon the NFSv4 protocol (RFC3530), and do not form part of, nor have any dependency on, the proposed NFSv4 Minor Version 1.
- When an NFSv4 client application performs a triggering action on a target directory beyond a server shared filesystem boundary, the client will automatically mount the associated server filesystem, and perform the operation on it. This "mirror-mount" will be transparent to the client application. [A client detects a server shared filesystem boundary when it encounters a directory which has a different "fsid" NFSv4 attribute than the containing directory]
- Any action on a target directory resulting in a vnode operation of either VOP_LOOKUP(target) or VOP_GETATTR(target) is not a triggering action.
- Any action on a target directory resulting in any other vnode operation is a triggering action.
- Any action on a parent directory containing the target directory resulting in a vnode operation of VOP_READDIR(parent) is not a triggering action.
- It will be possible for mirror-mounts to be nested at any server location. E.g. both /home & /home/user/project_foo may be mirror-mounts of separate filesystems.
- The mount point should appear to the user as a normal mount, similar to the appearance of automounted mounts.
- In particular, the contents of mnttab(4), the structure returned by statvfs(2), and the outputs of df(1M), mount(1M) & nfsstat(1M) "-m" will all be indistinguishable from a manual mount. An exception may be that nfsstat(1M) "-m" may include an additional field to note that the mount is a mirror-mount. However, existing fields will not change.
- The user should be able to identify that a particular mount was done by the mirror-mount mechanism, by use of a supplied MDB dcmd, or, preferably, in nfsstat(1M) "-m" output.
- 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, and will not be separately controllable.
- It will be possible to manually unmount a mirror-mounted filesystem, forcibly, if necessary.
- If an NFS filesystem is manually unmounted, then any mirror-mounted filesystems contained within it will also be unmounted.
- 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.
- Mirror-mounts must not cause any regression with existing automounter map setup.
- 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.
- It will be possible for mirror-mounts to be disabled system-wide using a sharectl(1M) setting.
- It will be possible for mirror-mounts to be disabled on a per-filesystem basis, with the "mirrormount | nomirrormount" mount options. The "mirrormount" mount option will be the default in Nevada, i.e. mirror-mounts will be performed by default.
- For any particular mirror-mount, if either the system-wide sharectl(1M) setting, or the per-mount mount option, are set to disabled, then the mirror-mount will not occur.
- Mount options will be inherited directly from the parent mount.
- Security-related mount options will be inherited directly from the parent mount. If the mount fails because of a security flavour issue, the normal NFSv4 security negotiation will be performed.
TBD - list man pages; mount_nfs(1M), ...
- System Adminstration Guide updates and man pages will be delivered.
The following functionality will not be delivered by this project, but may be delivered by a future project.
- For NFSv4-capable servers (only), providing the client's "/net" functionality by the mirror-mount mechanism, instead of by the automounter.
- Discovery of server namespace, or global network shared filesystem namespace, via initial mounts and referrals.
- Mirror-mounts for NFSv2/v3 clients/servers.
This project has a fairly narrow impact on Solaris. It makes a regularly performed sysadmin task somewhat easier, by automating much of it, and presents an enhanced filesystem view to the client users.System administrators may need to become familiar with the proposed sharectl(1M) setting and mount options.
This project depends on the functionality provided by the in-kernel mount part of the automounter enhancements. Although recently putback, this code does not yet have much test exposure.This project is closely linked with the NFSv4 Referrals project, and will share its implementation.
- 1.8 - 12th April 2007
- Edited for OpenSolaris
- 1.7 - 16th March 2007
- Use sharectl(1M) instead of SMF; change SMF Risk to discuss /etc/default/nfs
Removal of setting for auto-unmount timeout: use existing automounter setting
Observability via nfsstat(1M) "-m" output.
Inheritance of mount options (and security-related mount options)
- 1.6 - 27th November 2006
- formal approval draft
- 1.5 - 6th November 2006
- NFS team draft
- 1.3 - 20th October 2006
- I-team draft
- Project pages, for Mirror-mounts and Referrals
- http://opensolaris.org/os/project/nfs-namespace
- Mount Point Crossing. NFSv4 Protocol, RFC3530 Section 7.7.
- http://www.ietf.org/rfc/rfc3530.txt
The triggering actions on a target directory that will result in an automatic mirror-mount are defined in terms of their resultant vnode operations.From an API perspective: with the single exception of stat(2), all filesystem calls involving the target directory will trigger a mount. However, a readdir(3)/getdents(2) of the parent directory enclosing the target will not trigger a mount.
For example:
ls -d ${parent}/$targetwill not trigger a mount
- All other filesystem commands involving the target directory will trigger a mount
Automounter comparison: the automounter will only automatically mount nested mounts when encountered under /net.
Mirror-mounts will enable a "browsing" feature similar, but not identical, to the automounter.
When the automounter browsing option is enabled for indirect maps, it is possible to see the existence of automount trigger points before they are mounted:estale $ ls -ld /home/alice dr-xr-xr-x 1 root root 1 Oct 18 12:36 /home/alice estale $ mount | grep alice estale $Note that the attributes of the directory are generated by the client, and do not match reality on the server. The directory is given mode 0555, with root ownership, and the modification time is the current time. If the directory is mounted - e.g. by changing into the directory - the automounter completes the mount, and the real directory attributes are seen:estale $ ls -ld /home/alice drwxr-xr-x 79 alice pawns 20480 Oct 18 13:19 /home/alice(as well as its contents).Note that the automounter "/net" feature is a special case, where the automounter will automatically mount any server filesystems it traverses. The functionality proposed here is almost identical, but using solely NFSv4 mechanisms, with no involvement of the automounter, and with the enhancement of correctly presenting the directory attributes during browsing. In addition, of course, it is not tied to a particular trigger-point (/net).
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 mounts-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 dumThis 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.