OpenSolaris

Design Notes

Notes on a ZFS root pool etc...

• The root pool has to be a single slice (no raid-z or stripes)
• The root pool cannot grow past the end of that slice.
• For a mirrored root, each side of the mirror has to be on its own slice and the mirror will only be as large as the smallest side of the mirror.
• The booter can only access one side of the mirror.
• The root pool has a bootfs property which indicates the default bootable pool.
• The root pool contains the menu.lst in the main pool dataset.
• There can be more than one root pool but only one can be bootable.

Notes on LU + ZFS root

• Must already have a pool created for use with BE creation. This pool must be a legal root pool and does not support raid-z.
• The new BE creation leaves the old UFS BE in place and creates a new zfs BE. Once the zfs BE is created it is then upgraded. This gives the possibility to back up to the UFS BE and does not upgrade it or migrate it to ZFS.
• Each BE (including the BE from the initial installation) is made up of separate datasets. These are for things like /, /usr, /var, /opt
• The authoritative list of bootable datasets within a root pool will be the menu.lst file for both x86t and sparc.
• Each root pool will have its own menu.lst file and it will be the job of snapupgrade to keep them consistent, similar to what we do now where each ufs BE has its own menu.lst file. Entries in menu.lst can have "root" keywords to indicate what physical disk needs to be accessed to get to the root file system in the BE. The menu.list file in one root pool can use the "root" command to associate a menu entry with a pool on another device.

Investigate

• Upgrade with DSR
  • What needs to be there for IPS to eval and upgrade a pre-IPS image?
• Zone upgrade
  • Cloned zones space usage in upgraded BE
  • Additional software in zones
• Diskless clients
  • Do we need to continue to support this