show tree efficiency

Webster Dove rocket!dove at uunet.uu.net
Mon Oct 8 07:30:00 AEST 1990


Thanks to nfswatch I just discovered a significant innefficiency in our
nfs setup. We have one tree of filenames (starting at "/nfs/") on which
all our disks are mounted.  THe names are of the form

machine_alias:/nfs/machine_alias/disk_?

where machine alias is setup on the yp master to point to the physical
machine.  In this way, clients can have fstab entries like

machine_alias:/nfs/machine_alias/disk_? /nfs/machine_alias/disk_?

and not change them if the disk is moved (only the ypmaster alias need be
changed).  To simplify things for the users we have a pair of shadow link
trees

local_sun4:/local_sun4/... for sparcs and
local_sun3:/local_sun3/... for moto's

again, using machine aliases for the hosts.  A typical sparc would have an
fstab like

/dev/sd0a / 4.2 rw,noquota 1 1
athens:/usr /usr nfs rw,noquota 0 0
local_sun4:/local_sun4 /local nfs rw,noquota 0 0
asp_3:/nfs/asp_3/disk_a /nfs/asp_3/disk_a nfs rw,noquota 0 0
asp_1:/nfs/asp_1/disk_a /nfs/asp_1/disk_a nfs rw,noquota 0 0
asp_1:/nfs/asp_1/disk_b /nfs/asp_1/disk_b nfs rw,noquota 0 0
asp_2:/nfs/asp_2/disk_a /nfs/asp_2/disk_a nfs rw,noquota 0 0

where the server aliases are asp_[123].

Users then refer to files like /local/bin/tcsh or /local/gnu/bin/emacs or
/local/projects/asw/....

.. The advantages

Users don't need to know where files are physically mounted from.

Sysmgr's don't need to maintain multiple fstabs (except on the servers)
and they only need to maintain one shadow tree for each architecture (not
one on each client).

.. The problem

We get extra NFS requests from each client to lookup the shadow path
before accesing a given file.

.. The big question

Is there a way around these extra nfs accesses without sacrificing the
user or sysmgr simplicity?

Web



More information about the Comp.sys.sun mailing list