Hi William, > It can save the sysadmin from needing to know specific details of > disks on a system when composing a manifest. In the example, a disk > with at least 30GB is grabbed and used for a ZFS pool. The sysadmin > didn't have to know what the disk name was to have the pool for > /export1 created on it. This could simplify deployment of a > heterogeneous mix of computers with assorted disks - the same > generalized manifest could be used to pre-configure file systems > consistently on many, very different computers. > > Some maintenance benefits: > Simple reference names like 'device1' or 'bootdisk' could help the > user avoid typos that might come with repeatedly typing ctd or mpxio > names or volume ids. If a reference name is used and the disk > designation needs to change for some reason, it would have to be > changed in only one place - in the disk selection criteria section.
Thank you for providing the examples. I can see how this would be useful. >> >> >> Ok, so we won't allow specification of datasets for the non-root pool >> with AI by the user? > This doesn't address ZFS dataset specification, but it seems a > reasonable and useful extension to allow the user to specify ZFS > datasets on the zpools created. I will add this to the design proposal. Thanks, I think allowing specification of datasets would be more complete. Thank you for taking the time to respond to my endless questions :-). sarah
