Managing NFS and NIS, 2nd Edition - Mike Eisler [105]
The client may have the wrong mount point listed in its /etc/vfstab file. If you did not specify the architecture of the client correctly when using the AdminSuite software, the client's vfstab file is likely to contain the wrong mount information.
If you are unsure of how a mount and link combination will work, experiment on another diskless client having the same architecture. For example, mount /export/exec/Solaris_2.7_sparc.all/usr on /mnt, and then try a sample command to be sure you've mounted the right one:
client# mount wahoo:/export/exec/Solaris_2.7_sparc.all/usr /mnt
client# cd /var
client# /mnt/bin/ls
4lib dict krb5 oasys sbin ucblib
5bin dist kvm old share vmsys
X dt lib openwin snadm xpg4
adm games lost+found platform spool
aset include mail preserve src
bin java man proc tmp
ccs java1.1 net pub ucb
demo kernel news sadm ucbinclude
If commands are executed properly, then you should be able to mount /usr safely on the diskless client in question.
Configuration options
Adding disks to local clients opens two configuration options. You can use the local disk for swap space, or you can build an entire bootable system on it and put the root and swap filesystems on the local disk. This latter configuration is called a dataless client, and makes sense if the client does not need most of the local disk for a very large swap space. If the client has a large swap partition and uses it frequently, adding a local disk may improve performance by reducing the client's traffic to its boot server. In other instances, the local disk provides private storage for sensitive files.
Dataless clients contain no user or data files on their local disks. Everything on the local disk can be reconstructed from operating system release tapes or from system installation scripts. The local disks are used for the root and swap filesystems, while /usr and all other filesystems are NFS-mounted. The dataless architecture provides some performance advantages from both the client and server perspective, particularly when the client has a large swap space.
A significant portion — usually more than 50% and sometimes 90% — of a diskless client's network traffic is caused by reading and writing the root and swap filesystems. Clients with local disks place less of a load on the network and on the boot server by sending their swap traffic to this disk.
Dataless clients
You may choose to use the dataless client configuration if you have to support a few machines of a new client architecture and would have to carve the disk space out of the server's /export partition. Adding a local disk keeps the server configuration simple and puts all files specific to the new client architecture on the local disks.
The best network architecture for dataless clients is one in which desktop machines run application sets with large, randomly accessed virtual address spaces. If the machine has a reasonably high level of paging activity, depending on the speed of the network and capacity of the NFS servers, using a local disk improves performance. Dataless clients may appear to be more expensive per seat than diskless clients, since the diskless machines get root and swap space at "bulk" prices from the server. On the other hand, in a pure diskless client environment, you must purchase additional disk space to hold the clients' root and swap filesystems. If you allocate some portion of the server's cost as the cost of replacing local disks, the dataless and diskless architectures have much less of a price differential. Be careful when analyzing client/server cost projections. You'll get the fairest numbers when you compare the total cost of the desktop workstation, any local disk, and the desktop's share of the cost of servers providing root, swap, and user filesystems.
When you do add local disks, it's important to choose