The trouble with /var in unix systems

Mike Gerdts suggests using /var/share for sharing data between boot environments in his March 2008 post Future of OpenSolaris Boot Environment management.

The trouble with unix /var is that it is a grabbag, in that it is used both for storing system data (i.e., identity), as for storing application data.

/var/ is intended for variable data that should persist through a reboot: short lived temp files, spool directories for transient files (printing,mail), and whatever data applications might wish to store (/var/opt).

However, as said above, it also contains data about a systems 'identity', specific settings like cronjobs, printer settings, network configuration, definitions of services that altogether make up what the box 'is'. This also includes the list of installed software in /var/sadm. At some point these all moved into /var from /usr or /etc in ancient unix past.

Root was supposed to be small then, and did not contain a lot that could change, limiting the risk of a long fsck if there were a lot of modified files in the root fs. With just enough stuff to allow the system to boot, if you lost any other filesystem, if you had at least a running system you could attempt to repair or restore whatever was broken.

Mike's suggestion is very sound, as it does what is required. System identity is kept in the root fs (/), while application data, whether it's persistent or transient, goes into /var/share, keeping /var as part of the root fs, even though the 'share' name may be a bit of an unlucky choice - it's used in /usr/share and other places for architecture-neutral data that can be shared with other systems (nfs clients).