Drew,
Are you working on a new target.dtd for these changes? I really need
to see the DTD before I can comment comprehensively. I can possible
help you draft the dtd if needed?
Further comments in-line below:
<!-- single disk, single pool -->
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd" zpool="tank" />
</disk>
<logical>
<zpool name="tank" action="create" is_root="false" />
Should is_root not be "true" here (and repeated several times
below)?
</logical>
</target>
<!-- two disks, single pool, mirrored -->
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd" zpool="tank", vdev="tank_mirror"/>
</disk>
<disk>
<disk_name name="c3t1d0" name_type="ctd" zpool="tank", vdev="tank_mirror"/>
I assume the comma after "tank" above (and repeated several times
below) is a typo?
</disk>
<logical>
<zpool name="tank" action="create" is_root="false" />
<vdev name="tank_mirror" redundancy="mirror"/>
</zpool>
</logical>
</target>
Let's say that before installing, you already have a zpool on
your system and disk "c3t0d0" is part of it. If you specify the
above in your AI manifest, are you implicitly saying that the
old zpool should be destroyed?
<!-- 10 disks: Mirrored root + raidz datapool with log, cache, spare -->
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd" zpool="tank",
vdev="tank_root_mirror"/>
</disk>
<disk>
<disk_name name="c3t1d0" name_type="ctd" zpool="tank",
vdev="tank_root_mirror"/>
</disk>
<disk>
<disk_name name="c3t2d0" name_type="ctd" zpool="tank", vdev="tank_raidz"/>
</disk>
<disk>
<disk_name name="c3t3d0" name_type="ctd" zpool="tank", vdev="tank_raidz"/>
</disk>
<disk>
<disk_name name="c3t4d0" name_type="ctd" zpool="tank", vdev="tank_raidz"/>
</disk>
<disk>
<disk_name name="c3t5d0" name_type="ctd" zpool="tank", vdev="tank_raidz"/>
</disk>
<disk>
<disk_name name="c3t6d0" name_type="ctd" zpool="tank", vdev="tank_cache"/>
</disk>
<disk>
<disk_name name="c3t7d0" name_type="ctd" zpool="tank", vdev="tank_log"/>
</disk>
<disk>
<disk_name name="c3t8d0" name_type="ctd" zpool="tank", vdev="tank_spare"/>
</disk>
<disk>
<disk_name name="c3t9d0" name_type="ctd" zpool="tank", vdev="tank_spare"/>
</disk>
<logical>
<zpool name="tank" action="create" is_root="false" />
<vdev name="tank_root_mirror" redundancy="mirror"/>
<vdev name="tank_raidz" redundancy="raidz"/>
<vdev name="tank_log" redundancy="log"/>
<vdev name="tank_cache" redundancy="cache"/>
<vdev name="tank_spare" redundancy="spare"/>
</zpool>
</logical>
</target>
So, my (partial) summary of the changes to the DTD is as follows:
- <target_device> is being dropped
- <disk> can now only occur under <target> (and not also under <vdev>)
- <partition> can now only occur under <disk> (and not also under <vdev>)
- <slice> can now only occur under <disk> or <partition>
(and not also under <vdev>)
- <disk>, <partition> and <slice> are all getting 2 new (optional)
attributes: "zpool" and "vdev", whose values *must* be a forward reference
to a valid name attribute of a <zpool> or <vdev>, respectively
- Q: if there is only one zpool and/or vdev in <logical>, must the zpool
and/or vdev attributes be specified, or can we assume them?
- <target> is getting a new, optional, sub-element: <logical>
- the sub-elements of <logical> are 1 or more <zpool> elements
- Q: where do <swap> and <dump> go? under <target> or <logical>?
- <vdev> now has no sub-elements
Is this correct?
- Dermot
On 01/15/11 00:05, Drew Fisher wrote:
Dave,
I've attached what I think you're looking for. My ZFS-fu is weak,
though. Hopefully it's what you wanted. :)
Note: I used whole disks for these use cases to make the XML less
huge. In order to change to partitions or slices, the proper
sub-elements would be added to whichever disk you wanted to carve up,
but the zpool and vdev attributes would need to be moved from the
<disk_name> element.
Let me know if you'd like other use cases.
-Drew
I'd suggest agreeing on a few use cases that we need to cover and
expressing them out so that we can get a feel for them. Suggested:
- Single disk, single pool
- Two disks, single pool, mirrored
- 10 disks: Mirrored root + raidz data pool with log, cache, spare
Maybe some others, but those were a quick attempt at a broad range.
Dave
------------------------------------------------------------------------
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
