Gordon Ross wrote: >> 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 ?
It will not. The reasons were hashed out on smf-discuss when the Early Manifest Import project did their ARC/design review there. > >> 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). I admit I haven't closely followed the conversation until now, so don't have a specific (or at least an informed-enough) opinion to comment or offer a complete alternative to Sanjay's updated proposal. liane
