Alec Muffett wrote: >> But >> finally, and this is the critical problem, each user's home >> directory is now a separate NFS share. >> >> At first look that final point doesn't seem to be much of a worry >> until you look at the implications that brings. To cope with a >> distributed system with a large number of users the only managable >> way of handling NFS mounts is via an automounter. The only >> alternative would be to have an fstab/vfstab file holding every >> filesystem any user might want. In the past this has been no >> problem at all, for all your user home directories on a server you >> could just export the parent directory holding all the user home >> directories and put a line "users -rw,intr myserver:/disks/users" >> and it would work happily. >> >> Now, with each user having a separate filesystem this breaks. The >> automounter will mount the parent filesystem as before but all you >> will see are the stub directories ready for the ZFS daughter >> filesystems to mount onto and there's no way of consolidating the >> ZFS filesystem tree into one NFS share or rules in automount map >> files to be able to do sub-directory mounting.
Sun's NFS team is close to putting back a fix to the Nevada NFS client for this where a single mount of the root of a ZFS tree lets you wander into the daughter filesystems on demand, without automounter configuration. You have to be using NFSv4, since it relies on the server namespace protocol feature. Some other NFSv4 clients already do this. This has always been a part of the plan to cope with more right-sized filesystems, we've just not there yet. For NFSv2/v3, there's no easy answers. Some have experimented with executable automounter maps that build a list of filesystems on the fly, but ick. At some point, some of the global namespace ideas we kick around may benefit NFSv2/v3 as well. Rob T _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
