> Sharing /usr doesn't work as well as you might like. We did > this at Sun with diskless workstations. It turns out that > the server gets saturated with only a few workstations. I > think that about 10 workstations per server was the maximum.
Depends on how you do the sharing. In an AFS environment (where there is some local caching of common files), it's not too uncommon to have several hundred clients sharing the entire OS installation out of AFS space. The big nasty limit is network congestion. Using multiple AFS servers to split up parts of /export/root was a big win -- it allowed a lot of the filesystem access to occur in parallel rather than via a single large server. > Of course you can't share /usr/bin with different > architectures. Some other files in /usr are binary, and have > problems with different architectures. You'd have to invent something like the AFS @sys metavariable, which is resolved by the client. The way it works in AFS is you'd have the client /usr/bin be a symlink to /afs/foo.com/@sys/usr/bin, which gets resolved as /afs/foo.com/sun4/usr/bin on a sun4, /afs/foo.com/aix51l/usr/bin on AIX, etc. Perhaps Jim could use a similar approach -- have his servers with a minimum set of boot code to get on the network and get to AFS space, and then pull the rest of their code via AFS. He could then subdivide at any point in the hierarchy (and use the same method for any outboard servers as well). It'd reduce the footprint of his individual server instances to about 45M (plus local disk cache) and also solve the problem of having home directories everywhere. -- db
