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
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. :)
zfs-discuss mailing list