20 февраля 2015 г. 12:04:47 CET, Laurent Blume <[email protected]> пишет: >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 >[email protected] >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 _______________________________________________ oi-dev mailing list [email protected] http://openindiana.org/mailman/listinfo/oi-dev
