James Lever wrote: > With more people using Solaris and OpenSolaris with a ZFS backing > datastore they will be really wanting to use NFSv4 mirror-mounts, > which somewhat surprisingly are supported natively from linux clients > - at least the entire filesystem and all ZFS children show up with a > single NFSv4 mount. As this usage rises, especially in enterprise, > this type of bug will have more of a chance to be discovered.
James, Mirror mounts are client-side only - which simply means that Linux has equivalent capabilities in their client. The NFSv4 protocol is designed to make this easier - i.e., we always have the concept of PUTROOTFH which allows a client to discover the server namespace dynamically. One of the design goals of NFSv4 was to reduce all the traffic to one port to help people configure firewalls. So with PUTROOTFH, your mount command may never result in a MOUNT protocol going otw - it may all be straight NFSv4 traffic. We called it mirror mounts because the client NFSv4 code was *mirroring* what the user did with the mount command. We had some people who had been involved with the automounter and they made some really good decisions about the name space should be able to be traversed dynamically (i.e., if a new mount point is created, you see it near instantly and do not have to wait for the maps to be regenerated) and the capability of the mirror mounts to be automatically harvested if idle. The goal to have 'umount //srv_mnt' automatically recurse to unmount children was also a key design point. But enough gushing, you are right, the combination of the explosion of file systems presented by ZFS and mirror mounts is sweet. Tom