On 01/12/11 13:04, jean.mccormack wrote:
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.
I'm not sure I'm following why the elements under the vdev have no
meaning. With the current schema, my understanding of the elements
specified under vdev is that they do not have to be specified out on the
top level. Why would that be needed?
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?
Not that I know of. Where does it look like we're doing this?
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.
We're using the <disk> element structure definition in two places, but
I'm not sure I see what's terribly wrong with that. The instances of
the <disk> elements specified on the upper level are to allow users to
use AI to layout partitions/slices that are not used with any pool. The
fact that they're specified outside of any pool structure makes that
pretty clear.
With what's being proposed with the references, I just want to probe out
if that's absolutely needed since it'd seem to me that the elements that
they'd otherwise reference could just as easily be left under the
zpool/vdev as it resides today.
-ethan
Jean
_______________________________________________
caiman-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/caiman-discuss
