On 01/12/11 12:24 PM, Ethan Quach wrote:
Jean,
On 01/07/11 15:37, [email protected] wrote:
The current target schema allows for vdev specification
as follows:
<target_device>
<zpool name="mypool" is_root=true action="create">
<vdev redundancy="mirror">
<disk>
<disk_name name="c0t0d0" name_type="ctd"/>
...
</disk>
<disk>
<disk_name name="c0t0d1" name_type="ctd"/>
...
</disk>
<partition action="create" name="1" part_type="191">
<size val="5000mb"
</partition>
<partition action="create" name="2">
<size val="5000mb"
</partition>
<partition action="create" name="3">
<size val="5000mb"
</partition>
</vdev>
</zpool>
</target_device>
</target>
That is, when creating a 2 disk mirror and 3 partitions, how
does one know which disk these partitions should be created on?
There is no way of knowing as it currently stands.
So why couldn't we just remove the <partition> and <slice> elements
from being specifiable as direct children of the <vdev> element?
Wouldn't this clear things up as well since the <disk> element is
already defined to have <partition> and <slice> as children?
Then, we can say that the <disk> (<partition> <slice> ) elements
specified at the top level (directly under (<target_device>) is how
users specify to create disk/partition/slice just for the sake of
creating them, i.e to be created and not necessarily associated with
any pool.
Yes we could. Although there is concern that this isn't so great from a
user interface perspective. Why do you need to carry around all that
info in 2 places when it really means nothing in the vdev location?
That's where we got to the reference element.
It just seems that instead of having disk/partition/slice elements
embedded within vdev, it might be cleaner to simply have references
in the vdev element to a disk/partition/slice name. Thus, doing away
with needing to embed these elements within a vdev.
We've dabbled with using references in some previous bugfixes before,
and concern is that it would make things a little harder, for both the
user and us, because you have to specify values in two places that
have to be coordinated and match up.
But isn't that what we're doing already?
It would look something like this:
<target>
<target_device>
<zpool name="mypool" is_root=true action="create">
<vdev redundancy="mirror">
disk ="c0t0d0"
disk ="c0t0d1"
</vdev>
</zpool>
<disk>
<disk_name name="c0t0d0" name_type="ctd">
<partition action="create" name="1" part_type="191">
<size val="5000mb"
</partition>
<partition action="create" name="2">
<size val="5000mb"
</partition>
<partition action="create" name="3">
<size val="5000mb"
</partition>
<disk>
<disk_name name="c0t0d1" name_type="ctd"/>
...
</disk>
</target_device>
</target>
In the case a vdev is on a partition or a slice, the vdev
specification would change to something like this (totally
unrealistic but you get the idea):
<vdev redundancy="mirror">
disk ="c0t0d0" slice = "0"
disk ="c0t0d1" part = "3"
</vdev>
This is what I mean by redundant specification. With this example,
the user would also have to specify:
<disk name="c0t0d0">
<slice name="0"/>
</disk>
<disk name="c0t0d1">
<partition name="3"/>
</disk>
elsewhere in the manifest as well, and its pretty much the same exact
data.
Actually elsewhere in the manifest we'd have the full blown disk
structure. This would be only a reference to that. Right now we have a
full blown disk structure in 2 places.
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
