[oi-dev] Updating Hipster and GUI log-in breakage with mounted ZFS datasets

[Jim Klimov]

20 февраля 2015 г. 12:04:47 CET, Laurent Blume <laurent+oi at elanor.org> пишет:
>Le 2015/02/18 16:39 +0100, Jim Klimov a écrit: 
>> Nikola, in Alexander's defense - AFAIK it was not his 'arbitrary
>decision' that /opt is not officially supported as a separate dataset. 
>>
>> When Sun first introduced zfs-based rootfs (as opposed to ufs root
>and zfs userdata), its installer only offered optional placement of
>/var into a separate dataset (child of current root) - not /opt nor
>/usr as part of the OS package targets. I think this has not been
>changed since than (even if it was a regression compared to several ufs
>slices or lvm's). Things outside of this might have worked 'by chance',
>but otherwise they were not required nor guaranteed to. With other
>usecases, like my eagerness for split-roots, users are on their own. 
>
>to be fair, this problem is not new, and actually predates ZFS by a
>long
>time. At core, it's not exactly a separate dataset that's the problem,
>but sharing the same /opt dataset among different BE's.
>It appeared with Live Upgrade. From this point on, although it was
>supported to have a separate /opt, it was not supposed to be a shared
>one between BE's.
>Not only Solaris has always put system packages there, for historical
>(ie, bad) reasons (eg, SUNWmlib), but other packaged binaries also did,
>like Blastwave/OpenCSW.
>
>It was already documented in lucreate(1M) in 2001:
>
>     The lucreate command makes a distinction  between  the  file
>     systems  that  contain  the  OS-/,  /usr, /var, and /opt-and
>     those that do not, such as /export, /home, and other,  user-
>     defined file systems. The file systems in the first category
>     cannot be shared between the source  BE  and  the  BE  being
>     created;  they  are  always copied from the source BE to the
>     target BE.
>
>SunOS 5.8           Last change: 22 Oct 2001                    1
>
>Of course, when zfs appeared, the problem was exposed differently,
>because having a dataset on a different hierarchy or pool caused
>different issues, but it was already well established that /opt was not
>to be shared. LU could not cope with it without extensive changes on an
>already brittle infrastructure (and even later, it had plenty of
>problems when using separate datasets below system directories like
>/var).
>So they removed the option since rather than spend a considerate amount
>of time on getting a fringe case to work reliably with the already
>difficult to manage SysV packaging/patching system.
>That it was still split manually was a mistake (and I've seen it done
>more than once, with real breakage as a consequence, that I had to
>fix).
>
>Laurent
>
>
>_______________________________________________
>oi-dev mailing list
>oi-dev at openindiana.org
>http://openindiana.org/mailman/listinfo/oi-dev

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).

HTH,
Jim
--
Typos courtesy of K-9 Mail on my Samsung Android