> Gordon Ross wrote: > > What prevents the simple strategy of sharing all of /var? > > (Simple is beautiful:) > > > > Could we just move things that can't be shared to /etc?
And I should have added: And if necessary, make symbolic links for things the have to move and for which we don't control the applications looking for them... Would that work for the case of /var/svc/manifest ? > Some things, e.g. /var/svc/manifest are Public interfaces that we can't > just change easily. That particular one we're deprecating over time > (PSARC 2010/013), but we can't just move the public interfaces without > interfering with ISV applications. > > Though, arguably, your larger point should lead to guidance for any new > projects delivering to /var. (Sanjay, is your project going to provide > that guidance?) > > liane I guess the fundamental argument is: There are relatively few things in /var that can not be shared, so it's better to deal with those things that can NOT be shared as the exceptions, and make everything else shared across boot environments. As for the "versioned DB in /var" problem, one suffers either way: If that DB is kept per BE, you have stale data in alternate BEs. The version change on upgrade is easier to deal with. Typically, customers just want a reasonable way to "roll back" after an upgrade, so it's probably sufficient to snapshot the (shared) /var filesystem with a snap name that can be easily associated with the BE it goes with. Then if and when a roll back is necessary, either zfs clone or rollback /var to the snapshot that BE requires. It's not surprising to lose recent DB updates during a roll-back, and it may even be desirable (to completely restore prior state). Gordon
