[OpenIndiana-discuss] Split-root installations

Jim Klimov jimklimov at cos.ru
Fri Dec 6 20:07:49 UTC 2013


On 2013-11-17 03:50, Jim Klimov wrote:
> Hello all,
>
>    For years I've mentioned "split-root" installations of Solaris-like
> systems in such a way that the root filesystem (the BE) is represented
> by several datasets, such as a split-off /usr dataset. Also there may
> be some datasets shared between boot environments, such as the sinks
> for logs and crashdumps, and not all of these are required to live on
> the rpool at all. There are cases when all such tweaks may be desirable.

I see that beadm now includes an option to mount "shared" datasets with
a slightly different definition than used on my texts:

"Mount all ZFS file systems not under the BE's root dataset"

http://src.illumos.org/source/xref/illumos-gate/usr/src/lib/libbe/common/be_mount.c#369

This got me wondering whether the "proper" solution to support
split-root datasets should include "beadm mount" support to always
mount (RO or RW?) the datasets determined to be part of the boot
environment (via its /etc/vfstab, or as "shared" in my definition
and that of the fs-root-zfs script for the actually running BE:
contained in $rpool/SHARED with non-legacy mountpoint and canmount=on,
or later maybe based on a per-dataset zfs attribute instead).

To be honest, I wouldn't really bother to implement this in the C code,
especially given that "mount -s" exists (although an over-shoot for
this particular task), but presence of arbitrary paths deemed to be
part of a "core" filesystem structure might be required for i.e.
package management in the altroot. And I am not sure that "pkg" would
or should use "beadm mount -s" when it updates a clone of the current
BE... What do gurus think?

//Jim

PS: The strings in source say that "-s [ro|rw]" requires one of the
keyword arguments. That is usually written not with square brackets,
but curly braces.

http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/beadm/beadm.c#1187





More information about the OpenIndiana-discuss mailing list