On 02/20/15 12:35 PM, Jim Klimov wrote:
Thanks for the historic insight, much appreciated and more than I could
substantiate while walking with a phone ;)
Just for clarity, in my split-root setups I also do not propose shared /opt -
it is a child dataset of a rootfs and so is atomically versioned just like
other dirs that can contain system packages. I do also maintain that an rpool
should be self-sufficient to boot a running system that one can log into
remotely (even if a separate userdata pool has failed for example), so my
shared datasets for system data like /var/* stuff generally reside under
rpool/SHARED/*.
Nothing forbids however to extend the logical filesystem tree with other
directories - and shared datasets - such as /opt/netbeans in my recently
published screenshot, or some /opt/firefox for Nikola - where the software
lifecycle and versioning is managed outside the OS image (manually built, or
binary tarballs, or a non-OS type of package, etc.)
Separate datasets even for parts of the core OS image still do make sense for
separation of dataset options - compression, quotas, snapshot schedules, etc.
And even more so for non-core-OS stuff (e.g. snapshot the /opt/firefox or
/opt/netbeans, roll up an upgrade, test it, and rollback if you don't like or
kill the old snap to save space - all separately from the OS package lifecycle).
Hi, following your insightful discussion, I removed practice of
momunting /opt to separate dataset,
but employed mounting only sub-direcories of /opt (/opt/sfw , /opt/Adobe
etc) as separate datasets.
I embraced practice of using rpool/SHARED/dir datasets for shared
sub-directories between BE's.
Thanks! :)
I will test updating from August 2014 Hipster 2014.1 to Hipster 20141010
(newest 2014.1) and see if it goes right and report it how it behaves
during update Thus far, no complaints from running BE.
I also believe that split-root installs are great and needed thing for
serious system installs and I like using that OS ability. Thank you Jim,
for telling us about it! ;)
_______________________________________________
oi-dev mailing list
[email protected]
http://openindiana.org/mailman/listinfo/oi-dev
