I''m currently experimenting with ZFS to gain experience for an early
production deployment (probably even in Solaris 10 Update 2 Beta).
There''s one case where I''m running into a problem. Consider
the following
filesystem hierarchy (for the OpenSolaris sources and objects), located on
sequoia, an Enterprise 3000 currently running snv_33:
/export/os
/export/os/src
/export/os/src/on-20060307
/export/os/obj/i386/on-20060307 (clone of /export/os/src/on-20060307)
/export/os/obj/sparc/on-20060307 (another clone of /export/os/src/on-20060307)
and probably more clones (e.g. derived from the previous ones to quickly
build/test smaller changes).
If I want to automount this on other systems instead of having several
copies of the workspaces locally on the clients, to achieve the following
client-side layout
/opt/os
/opt/os/src
/opt/os/src/on-20060307
/opt/os/obj
/opt/os/obj/on-20060307 (corresponding to $CPU of the client)
I could only come up with the following map structure:
/etc/auto_master:
/opt auto_opt_sol2
/etc/auto_opt_sol2:
os \
/ sequoia:/export/os \
/src -fstype=autofs auto_opt_os_src \
/obj -fstype=autofs auto_opt_os_obj
/etc/auto_opt_os_src:
* sequoia:/export/os/src/&
/etc/auto_opt_os_obj:
* sequoia:/export/os/obj/$CPU/&
This has a couple of problems:
* I cannot access /opt/os/src directly, only subdirs, and loose
browsability, unless I want to manually add every subdir to the relevant
maps.
* This causes an inconvenient explosion of the number of maps if there are
several hierarches where one wants to take advantage of ZFS
snapshots/clones in a similar way. This is especially tedious with YP
(which we still use) since initially getting the maps to the yp slaves is
a cumbersome (manual) process.
All this is probably unavoidable with NFSv2/v3, since every subdir needs to
be mounted individually, but with NFSv4 it should be possible to mount a
couple of high-level directories to achieve the desired client-side
filesystem layout and be able to access the subdirs without individual
mounts.
To avoid the explosion in the number of maps, it would be convenient to
have multi-level indirect maps, e.g. something like
os \
/ sequoia:/export/os \
/src \
/ sequoia:/export/os/src \
/* sequoia:/export/os/src/& \
/obj \
/ sequoia:/export/os/obj/$CPU \
/* sequoia:/export/os/obj/$CPU/&
I couldn''t get this or something similar to work right now, and also
ran
into the problem that & seems to expand to the primary key (os in this
case) only, so you have no way to refer to the expansion of /* here.
Also, I stumbled across the lack of umount -f support for AutoFS: I had
misconstructed the maps several times during my experiments, and was later
unable to umount e.g. /opt/os/obj on the client (an autofs mount) if the
map entry had changed. I only get EBUSY; the only `solution'' was to
reboot
the clients ;-( This may be a last resort during testing, but is a
nightmare if production systems are affected (which happened to me before).
Last but not least, where''s the best place to discuss
Automounter/AutoFS
issues? I could only think of the NFS community for now, maybe there
should be a broader filesystem community with an Automounter/AutoFS (and
separate NFS, ZFS, UFS, ...) projects?
Rainer
-----------------------------------------------------------------------------
Rainer Orth, Faculty of Technology, Bielefeld University