[OmniOS-discuss] Internal pkg error during a test r151010 to r151014 upgrade

[Volker A. Brandt]

>  I fundamentally disagree with this view of disk space. ZFS
> snapshots are only cheap if you do not have data churn. To the
> extent that you have churn in files, snapshots use up increasing
> amounts of space over time (because an increasing amount of old data
> has been removed in the current version of the filesystem and is
> preserved only by the snapshot).
> 
>  The reason we made /opt a separate ZFS filesystem and I'd certainly
> prefer to keep it that way is that we're concerned about churn in
> non-OmniOS parts of /opt (which I thought was basically 'all of
> them') affecting space used by BEs.
> 
>  To the very limited extent that we care about the equivalent of BEs
> for 'our' portions of /opt[*], we'll manage that explicitly
> ourselves instead of relying on BEs, because we consider the two to
> be decoupled. Saving 'our' /opt's state or switching around has
> almost nothing to do with saving and switching core OS state. Trying
> to manage the two through the same mechanism would in fact be an
> anti-feature for us.
> 
>  And to answer the next question: with relatively small SSDs as the
> root drives and relatively large amounts of physical memory (and
> thus relatively large crash dumps if/when we need them), disk space
> really is a limited quantity. We've already had to reduce OmniOS's
> rpool/dump space well below what the system would have preferred to
> have.

So, to summarize, your /opt is:

- confined in a small rpool

- subject to high turnover in a subdirectory (e.g. "/opt/pkg")

- managed completely separately from the rest of the rpool

- independent of any BE

I would hazard a guess that this is not "standard" /opt usage. :-)
However, it is clear why you want a separate /opt in this case.
If you can confine the "churn" to a subdirectory ("pkg" or whereever
your pkgsrc-delivered apps live), then you might want to consider
just making that subdirectory a separate dataset.


Regards -- Volker
-- 
------------------------------------------------------------------------
Volker A. Brandt               Consulting and Support for Oracle Solaris
Brandt & Brandt Computer GmbH                   WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: vab at bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"