Please find draft of scope/requirements and design for supporting
Multiple Disk and Multiple Pool's in the Automated Installer (AI).
Would appreciate any feedback/comments.
Requirements / Scope:
- Provide basic support for Multiple Disk and Multiple Pool
specification in
an AI Manifest. Schema will include the ability to set properties on
pools
and datasets.
- Complex disk layouts including ability to create cache, intent log
and spare
ZFS volumes are not part of the scope of this project. It is
perceived that
these will be implemented via a ZFS supported serialization scheme. The
schema needs to designed to support this, and discussion with the
ZFS team
has been initiated to determine if they can support this.
- Provide support for Multiple Disk/Pool specifications in an AI manifest,
whilst maintaining the current default specification if possible, and
attempt to map currently defined ZFS support from Jumpstart profiles.
- Analysis of current support for ZFS in JumpStart will be performed
as a guide
and some (or all) of the ZFS support in JumpStart may be included in
this
specification.
Design :
- AI Manifest :
- Design schema for AI manifest which will facilitate Multiple Disk and
Multiple Pool support.
- ZFS Multiple Pool Support will include
- Root pool specification, can only exist on single disk or mirrored
disk, Cannot exist in Concatenated or RAID configurations.
Design should enable ease of extension should these be supported by
ZFS in the future. Root pools must be SMI VTOC with slices, GPT
labeling
not supported yet.
- Data pool specification, created on single, concatened, mirrored, or
RAID configurations with current default GPT label.
- A disk virtual device as specified in zpool manpage can be whole
disks,
slices, partitions or files. However it is recommended to use whole
disks.
- Pool Types :
- Non-Redundant Pool Configurations (Dynamic Stripe)
Possibly including :
the following :
- Single disk root pool
- Optional Single disk or concatended disk data pools
- Optional Dump volume (either on root or separate pool) of single
or concanenated disks.
- Optional Dump volume (either on root or separate pool) of single
or concanenated disks.
- Redundant Pool Configurations
- Mirror (2 or more whole disks)
- Mirrored Root configuration
- Optional Mirrored data disk pools
- Optional Dump must be on root pool
- Optional Swap can be on root pool or separate pool of
single or
concatenated disks, mirrored swap does not make sense.
- RaidZ, RaidZ1, RaidZ2, RaidZ3
- Only used for optional Data disks
- Other vdev types
- Spare - Hot pluggable spare disks
- Only for mirrored or RaidZ configurations
- Use disks equal or larger than largest disk in pool(s) spare
is being attached to.
- Can be added to more than one pool but must be on same system
- Log - Separate ZFS Intent Log (Sometimes referred to as ZIL)
- Used for performance improvements,
- Recommended that log device is mirrored
- Min Size of 64MB
- Max Size recommended to be 1/2 the size of Physical Memory.
- Only for Non-Redundant(Dynamic Stripe) or mirror
configurations.
- Root Pools cannot have separate log devices
- slog's can be created on separte disks (SSD, NVRAM, etc),
or disk slices.
- Cache - Increase random read speed
- Cache devices cannot be mirrored or part of RaidZ
configuration
- Complex pool configurations may not be considered here, this will
depend
on whether a serialization scheme can be suppored by ZFS.
- Re-Define (if neccessary), default.xml minimum/recommended
configuration.
- Ensure ability to name pools is included in schema definition
- liborchestrator :
- Define new NVPAIR's to match required data being passed from
auto_install
- libti
- Define new API's if required for multidisk/pool support
regards
Matt
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
