Generally, if you install OpenIndiana with the wizard, it creates your
rpool for you, and the greatest influence you have on this process is to prepare the partition which would be wiped to create a default
The information and procedures below can help if you are migrating your system to a new
rpool device, or perhaps if you are into writing new installation wizards.
The bootable "root" pools have some limitations compared to general-use "data" pools:
rpoolto be sufficient at boot-time (which can include recovery from breakage of some devices), the pool must be a single-disk or a
mirrordevice, not a
raidzset. For the same reasons, it can not include a
rpoolcomponent should be a Solaris SMI slice encapsulated (for x86/x86_64) in an MBR table. This makes it tricky to create
rpools on devices sized over 2TB which command a EFI/GPT table (shims are possible, but unsupported, to create and maintain an MBR table which addresses in primary partitions the same ranges as the GPT table, to specify the legacy OS partitions).
rpoolslices on SSDs and "Advanced Format" HDDs, you might need to prepare the partition table as outlined in Advanced - Creating aligned rpool partitions.
compression=lz4). Certain datasets, such as
rpool/exportor components of the root filesystem hierarchy per Advanced - Split-root installation may be compressed with whatever algorithm – they are only processed and mounted by the illumos kernel with complete ZFS support.
dedupon a root pool, it was advised on the mailing lists not to do so. Less complexity is better for the system data.
rpoolis an important component of your system, in matters of both performance and reliability. You should keep it from overflowing (i.e. by setting up the split-root configuration and enabling quotas on potentially obese datasets – such as
/var/crash, or store such datasets in a different pool). In order to increase space on the
rpool, and to reduce writes to the device which houses it (in case of SSD), you might want to configure the
swapvolumes to be stored on another pool as well. It is generally established that modifications to a filesystem (writes and deletions) are somewhat riskier operations than just reads, and given the importance of the
rpoolfor booting and recovering your system, you should consider everything non-OS (including user data and local zones) on a different pool.
Now, assuming that you have already prepared an MBR partition and marked it as bootable, and prepared a Solaris SMI table in this partition, let's make some
rpool, but such pools won't be readable from older software versions.
zfs-auto-snapshotservice to make regular snapshots of datasets on this pool, whenever this service would be enabled.
Now, let's make the
swap volumes the way the installation wizard makes them (as of oi_151a8):
rsvdvolume and free up operational space.
Now, let's prepare a simple dataset structure for the traditional monolithic root filesystem:
The administrative user's home also lives in
rpool, and it can be compressed well:
To go deeper with compressing parts of the operating environment to save some space and IOPS, see Advanced - Split-root installation.
...After you've installed or migrated the OS to this new
rpool, don't forget to make it bootable:
Finally, as a trick that can help to quickly export and re-import the
rpool in the Live Media or comparable environment, you can do something like this: