Hi William, > Hi Sarah, Caimans, > > Sarah Jelinek wrote: >> I said: >>> >>> Target devices can then have symbolic names. The symbolic name can >>> be used in vdevs in zfs pool definitions. Examples follow below. >>> >>> The default disk reference names are of the form "deviceN" where >>> N=1....number of >>> devices. A custom name for a disk can be created using element: >>> ai_target_device/reference_name, and must be unique alphanumeric >>> string with underscores. >>> >> >> What is the benefit of allowing the reference naming for a device? I >> am not getting why we would want to add this level of indirection to >> the device specification. > [I mistakenly referred to "reference names" as "symbolic names" above, > so to recap...] > The reference names can be used in zfs pool definitions, so that you > can automatically select disks by criteria *other than disk name*, > name them, then specify slices on them as vdevs in a pool or mirror. > From the AI manifest example below, the second disk selected has a > reference name: > <reference_name>newpooldisk</reference_name> > Then a slice from the disk is used as a vdev from a zfs pool. In > section ai_zfs_pool: > <vdev> > newpooldisk.s0 <!-- use selected disk named "newpooldisk", slice > 0 --> > </vdev> > The disk has to meet the manifest criteria of being over 30G. > > Reference names are not used outside the manifest processing - they > are in no way permanent.
Ok, I got this part. I am just not sure what this adds for the user experience. Does it help the user in some way to categorize their disks? If you could provide examples on how this makes their experience better I would appreciate it. I am not saying it's wrong, just want to understand how this adds value. >> >>> Implementing root zfs pool (rpool) >>> >>> The manifest currently allows specification of rpool. >>> ai_target_device/install_slice_number indicates the root pool >>> slice. If not specified, slice 0 of the 1st disk in the list is >>> assumed to be the root. >>> A mirror slice vdev can be declared within the ai_target_device: >>> - unique device identifier (ctds, mpxio, /device node, reference >>> name of a selected disk) >>> - slice number >>> This results in the command: >>> zpool create <poolname> <install slice> [<mirror vdev>] >>> If the pool exists, doing the "zpool create" will overwrite the >>> existing pool. >> So, we are allowing the users to specify the root pool names? Or is >> this for any pool? > Yes, for any pool. "rpool" is the hard-coded root pool name in the > installer, and this will have to be carefully generalized. >> Also, if we overwrite the pool, we don't give the users a chance to >> realize their mistake. Are we sure we want the default to be >> overwrite? Maybe we should require they explicitly set an overwrite >> flag or something to ensure they get what they thought they were >> asking for. > Good point. We will have flags that are required to overwrite the > pool if it exists. >> >>> >>> The target_device_option_overwite_root_zfs_pool can be done as follows: >>> - import named rpool >>> - delete datasets that comprise the rpool, using "zfs destroy >>> <dataset>" >>> - proceed with installation an usual >>> >> I assume these notes above are how we would implement overwriting the >> existing zpool? > Yes. >>> zfs pool creation: >>> A pool consists of a set of vdevs. At this time, the vdevs are >>> slices, so they consist of a unique disk identifier (can be ctds, >>> mpxio, /device, or reference name) plus a slice number. >>> >>> Mirrors consist of list of vdevs and can be listed in the same way. >>> >>> General definition for a zfs pool (not the root pool): >>> [reworked below] >> >> It isn't clear to me if we are going to allow: >> -naming of the root pool by the user? >> -Creation of multiple pools during AI, with user naming >> >> Are we allowing for both? > Yes. Sorry this was unclear - I wrote this is a bit of a rush. >> >> Also, what zfs datasets will be created on the non-root pools? Are we >> going to allow for specification of these? > The pseudo-XML for section ai_zfs_pool (reworked below) was intended > for non-root ZFS pools. > > Here is some pseudo-XML to create or reuse a *root* pool: > ai_zfs_root_pool > action=create > name - the pool name (defaults to rpool) > id - the guid of an existing rpool, to resolve naming conflicts > overwrite_existing_pool (if we want to reuse an existing pool without > redefining it) > mirror_type (regular mirror, raid, or raid2) > mirror (0 or more mirror definitions, each specifying a slice to > mirror the install slice) > /ai_zfs_root_pool > > The root pool would be installed into a slice - a vdev list for root > pools is not possible at the moment, I believe. > > To delete a root pool as a separate action: > ai_zfs_root_pool > action=delete > name - the pool name > id - the guid, to resolve naming conflicts > /ai_zfs_root_pool > > General definition for a zfs pool (not the root pool): > ai_zfs_pool (zero or more ZFS pools) > action=create > name - the pool name > vdevs (1 or more vdev definitions or a set) > mirror_type (regular mirror, raid, or raid2) > mirror (0 or more mirror definitions, each containing a list of vdevs) > mountpoint (a zpool property) > overwrite_existing_pool (if we want to reuse an existing pool without > redefining it) > /ai_zfs_pool > > ai_zfs_pool > action=delete > name - the pool name > id (the pool guid, if name conflict) > /ai_zfs_pool > > NOTE: not all of the XML elements are shown here - the focus is on > multiple device details. Ok, so we won't allow specification of datasets for the non-root pool with AI by the user? >> >>> >>> Format for vdev: >>> disk_name - real (ctds, mpxio, /device node) or reference name of >>> selected disk >>> slice - valid slice number 0,1,3-7 >>> >>> Example: install on boot disk, use some selected disk as raid2 >>> mirror, and use another selected disk over 30GB for zfs pool newpool >>> mounted at /export1 >>> <ai_target_device> >>> <target_device_select_boot_disk> >>> <mirror>mirrordev.s0</mirror> <!-- put mirror selected disk named >>> "mirrordev", slice 0 --> >>> <mirror_type>raid2</mirror_type> >>> </ai_target_device> >>> <ai_target_device> >>> <reference_name>newpooldisk</reference_name> >>> <target_select_min_size>30<target_select_min_size> >>> <target_device_overwrite_disk/> <!-- erase disk, use whole disk >>> for slice 0 --> >>> </ai_target_device> >>> <ai_target_device> >>> <reference_name>mirrordev</reference_name> >>> <!-- assume that disk is appropriate for raid2 mirror --> >>> <target_device_overwrite_disk/> <!-- erase disk, use whole disk >>> for slice 0 --> >>> </ai_target_device> >>> <ai_zfs_pool> >>> <name>newpool</name> >>> <mountpoint>/export1</mountpoint> >>> <vdev> >>> newpooldisk.s0 <!-- use selected disk named "newpooldisk", >>> slice 0 --> >>> </vdev> >>> </ai_zfs_pool> >>> >>> For further consideration: >>> rpool deletion: >>> is there a use case for this? Should this be defined? >>> zfs pool deletion: >>> is there a use case for this? Should this be defined? >> >> Seems to me If we want to allow for full management for users for >> multiple disks, we should enable zpool deletion, rpool or otherwise. >> We need to work through the use cases for when we will either >> automatically delete a pool or when we require user specification to >> do this. > So we will require actions (create, delete) for pools as we do for > slices and partitions, then. > thanks, sarah *****
