dove@uunet.uu.net (Webster Dove) (10/08/90)
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