On 5/27/2010 9:30 PM, Reshekel Shedwitz wrote: > Some tips… > > (1) Do a zfs mount -a and a zfs share -a. Just in case something didn't get > shared out correctly (though that's supposed to automatically happen, I think) > > (2) The Solaris automounter (i.e. in a NIS environment) does not seem to > automatically mount descendent filesystems (i.e. if the NIS automounter has a > map for /public pointing to myserver:/mnt/zfs/public but on myserver, I > create a descendent filesystem in /mnt/zfs/public/folder1, browsing to > /public/folder1 on another computer will just show an empty directory all the > time). > The automounter behaves the same irregardless of whether NIS is invovled or not (or LDAP for that matter.) The Automounter can be configured with files locally, and that won't change it's behavior.
The behavior your describing has been the behavior of all flavors of NFS since it was born, and also doesn't have anything to do with the automounter - it was by design. No automounter I'm aware of is capable of learning on it's own that 'folder1' is a new filesystem (not a new directory) and mounting it. So this isn't limited to Solaris. > If you're in that sort of environment, you need to add another map on NIS. > Your example doesn't specify if /public is a direct or indirect mount, being in / kind of implies it's direct, and those mounts can be more limiting (more so in the past) and most admins avoid using the auto.direct map for these reasons. If the example was /import/public with /import being defined by the auto.import map, then the solution to this problem is not an entirely new entry in the the map for /import/public/folder1, but to convert the entry for /import/folder1 to a hierarchical mount entry, specifying explicitly the folder1 sub mount. A hierarchical mount can even mount folder1 from a different server than public came from. In the past (SunOS4 and early Solaris timeframe) heirarchical mounts had some limitations (mainly issues with unmounting them) that made people wary of them. Most if not all of those have been eliminated. In general the Solaris automounter is very reliable and flexible and can be configured to do almost anything you want. Recent linux automounters (autofs4??) have come very close to the Solaris ones, however earlier ones had some missing fieatures, buggy features, and some different interpretations of the maps. But the issues described in this thread is not an automounter issue, it's a design issue of NFS - at least for all versions of NFS before v4. Version 4 has a feature that others have mentioned called "mirror mounts" that tries to pass along the information trequired for the client to re-create the sub-mount - Even if the original fileserver mounted the sub-filesystem from another server! It's a cool feature, but NFS v4 suport in clients isn't complete yet, so specifying the full hierarchical mount tree in the automount maps is still required. > (3) Try using /net mounts. If you're not aware of how this works, you can > browse to /net/<computer name> to see all the NFS mounts. On Solaris, /net > *will* automatically mount descendent filesystems (unlike NIS). > In general /net mounts are a bad idea. While it will basically scan the output of 'showmount -e' for everything the server exports, and mount it all, that's not exactly what you always want. It will only pick up sub-filesystem that are explicitly shared (which NFSv4 might also only do I'm not sure) and it will miss branches of the tree if they are mounted from another server. Also most automounters that I'm aware of will only mount all the exported filesystems at the time of the access to /net/hostname, and (unles it's unused long enough to be unmounted) will miss all changes in what is exported on the server until the mount is triggered again. On top of that, /net/hostname mounts encourage embedding the hostname of the server in config files, scripts, and binaries (-R path for shared libraries) and that's not good since you then can't move a filesystem from one host to another, since you need to maintain that /net/hostname path forever - or edit many files and recompile programs. (If I recall correctly, this was once used as one of the arguments against shared libraries by some.) Because of this, by using /net/hostname, you give up one of the biggest benefits of the automounter - redirection. By making an auto.import map that has an entry for 'public' you allow yourself to be able to clone public to a new server, and modify the map to (over time as it is unmounted and remounted) migrate the clients to the new server. Lastly using /net also diables the load-sharing and failover abilities of read-only automounts, since you are by definition limiting yourself to one hostname. That was longer than I expected, but hopefully it will help some. :) -Kyle _______________________________________________ zfs-discuss mailing list zfs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
