In a previous entry I made an offhand comment that diskless clients still needed a separate / filesystem for each client. This is true for how diskless clients were generally implemented, but technically not true in general; it's possible to build a diskless client environment with even a shared root directory.

The truth is that most of the contents of / are common between all machines; there is just not that much system-specific information in the root filesystem, especially if your diskless machines were generic (which they usually were). So all you need for a shared root is to put all of that system-specific information in a separate filesystem (well, a separate directory hierarchy) and then arrange to mount that filesystem in a fixed place very early on in the boot process.

(Then you make all of the system-specific files in / be symlinks that point into the fixed mountpoint for the system-specific directory.)

How do the generic boot scripts in the generic / know which system's directory to mount? Clearly you need a piece of system-specific information to know what system you are, but fortunately diskless machines already have one, namely their IP address, which they know by the time they can NFS-mount the root filesystem.

I doubt that this is a novel idea, so why didn't any Unix vendor do this back in the days when diskless systems were big? I don't know for sure, but I suspect that it was a combination of there being a number of painful practical issues that would have to be solved, plus there's probably not all that much disk space to be saved. Using separate / filesystems for each diskless client was simpler enough to win.

(You could also get most of the savings with hardlinks and cleverness, although I don't know if any Unix vendor officially supported that.)