Boot environments and /var - what should be shared/unshared?

[Brandon J. Wandersee]

Arthur Chance writes:

> I've been using beadm boot environments for a while now, but still
> haven't seen a definitive reference for which parts of /var should be
> shared across boot environments and which should be per environment. Is
> there such a document, or is everybody still busking it?
>
> Some top level directories in /var seem fairly obviously in need of
> sharing, others less so, and /var/db seems to be a horrible mix of stuff
> that could be shared across releases and stuff that might break horribly
> if shared over major revisions. (That's "might" because I have no idea
> if it would in practice.)
>
> I doubt whether any of this would matter (except for space) if one
> simply rolled forward monotonically, but a roll back because of
> problems, or simply switching between development environments, could
> lose necessary updates if the directory hadn't been shared when it
> should have been.

I suppose I can't give you a "definitive reference," but I selected
things to omit from boot environments based on advice in the book
/FreeBSD Mastery: Advanced ZFS" by Michael W. Lucas and Alan
Jude. Here's what I've got, follow by the reasoning behind it:

|  NAME                     USED  AVAIL  REFER  MOUNTPOINT
|  workbox/VARIABLE        3.82M  72.5G   144K  none
|  workbox/VARIABLE/crash   144K  72.5G   144K  /var/crash
|  workbox/VARIABLE/log    2.86M   497M  1.80M  /var/log
|  workbox/VARIABLE/mail    340K  72.5G   196K  /var/mail
|  workbox/VARIABLE/tmp     360K  72.5G   144K  /var/tmp


1. /var/crash, /var/tmp: The contents of these directories are supposed
                         to store non-volatile data, some of which is
                         relevant to recovery. You don't want it
                         disappearing after a reboot, or want to have to
                         find and mount an extra ZFS dataset in order to
                         access it.
   
2. /var/mail, /var/log: Mail and logs are generated by applications as
                        well as the base system, and are
                        time-sensitive. You don't want these skipping
                        around through time at all, but it's more
                        egregious if you lose a day's worth of logs for
                        your web server because something in the base
                        system got messed up. That's exactly the sort of
                        thing the BSD filesystem hierarchy was designed
                        to prevent in the first place.


I've also got a couple datasets mounted in /var, but as children of
another tree:

|  workbox/APPS           6.26G  72.5G  5.42G  /usr/local
|  workbox/APPS/config    7.17M  72.5G  6.22M  /usr/local/etc
|  workbox/APPS/pkgCache   238M  2.77G   236M  /var/cache/pkg
|  workbox/APPS/pkgDB      162M  72.5G  81.5M  /var/db/pkg

This way I can roll back package upgrades all at once without touching
anything else on the system. I used to handle packages/ports within boot
environments, but decided to separate them once I realized that doing so
could make them grow pretty large with successive upgrades. Having your
ports/packages tied to boot environments is really only useful when
tracking -CURRENT or performing a major version upgrade, so I see it as
a waste to constantly take up space in preparation for something that
happens once every couple years, for which I'll have ample warning and
preparation.

Someone else might come along with better ideas, but I suspect a lot of
it depends on taste and personal need.

-- 
::  Brandon J. Wandersee
::  brandon.wandersee at gmail.com
::  --------------------------------------------------
::  'The best design is as little design as possible.'
::  --- Dieter Rams ----------------------------------