Dave Miner wrote:
>
> What do these variants buy us? Why would I use them vs. the other form?
>
I presume you're talking about the variations on specifying zfs file
systems. See below.
> William Schumann wrote:
>> Elaborating upon zfs and zpool enhancements to AI. BE considerations
>> - add name of BE to create.
>>
>> As always, feedback is desired. Also opinions as to the value of
>> these features - how useful are they?
>>
>> The concept of overwriting existing pools was reconsidered. The
>> question here is what to do with a pool if it has <zpool_create> and
>> it already exists. "Overwrite" is a misnomer and will not be used here.
>>
>> There are a few different pool reuse cases:
>> 1) the user wants to reuse the manifest and preserve the pool the
>> created with the manifest
>> 2) the user wants to remove contents from the pool and reuse it
>> without having to know its options or vdevs
>> 3) the user wants to redefine the pool, changing options or vdevs
>>
>> For the first option, adding boolean attribute "preserve" will result
>> in any associated manifest definitions of vdevs, mirrors, and options
>> being ignored, and the zpool will be unchanged, except for BEs in the
>> root pool (discussed below)
>>
>> For the second, adding boolean attribute "destroy_all_datasets" will
>> cause any datasets to be destroyed, including any BEs
>>
>> For the third, the user must <zpool_destroy>, then <zpool_create>
>> according to the new specifications.
>>
>> For root pools, the preserve options become more interesting. If the
>> root pool exists, it could contain BEs that the user may want to
>> preserve. Propose for the zfs_root_pool section, add BE_name
>> element. If named BE does not exist, just install OpenSolaris into
>> that BE. If it does exist, fail the install unless boolean attribute
>> destroy_be_if_it_exists is true in which case the BE is first
>> deleted, then recreated. When a BE is not named, take the default
>> behavior, which is to use 'opensolaris' BE, destroying it if it exists.
>>
>> My original draft of the AI manifest schema allowed the user to
>> create a filesystem in the context of a zpool:
>> <ai_manifest name="default">
>> ...
>> <ai_zfs_pool>
>> <zpool_create name="zoolpool">
>> <vdev>c0t0d0</vdev>
>> <zfs_fs_create path="mynewzfs"/>
pool-relative form - in the context of a zpool_create
This localizes the definition, making the association with the pool
readily visible
Also, a slight convenience in not having to retype the poolname to
define the zfs file system
>> </zpool_create>
>> </ai_zfs_pool>
>> would result in:
>> zpool create zoolpool /dev/dsk/c0t0d0
>> zfs create zpoolpool/mynewzfs
>>
>> Added the ability to create a zfs file system without the pool
>> context, at the top XML level:
>> <ai_manifest name="default">
>> ...
>> <zfs_fs_create path="poolname/fully_specified_path"/>
(above) absolute form - full specification of file system, consisting of
pool name + '/' + path
used when the zpool already exists - there is no zpool_create.
>> would result in:
>> zfs create poolname/fully_specified_path
>>
>> Also added to the manifest the ability to create a zfs filesystem as
>> a child of another zfs filesystem.
>> <zfs_fs_create path="mynewzfs">
>> <zfs_fs_create path="child_of_mynewzfs"/>
>> </zfs_fs_create> <!-- end mynewzfs -->
(above) nested form - in the context of a zfs_fs_create
same as in the pool-relative form - makes the child/parent
association visible
The absolute form - full zfs file system specification, could be done in
place of the other two.
William
