Evan,
On 01/18/11 18:30, Evan Layton wrote:
On 1/18/11 11:01 AM, Drew Fisher wrote:
On 1/18/11 10:12 AM, Dermot McCluskey wrote:
Drew,
A couple of follow on points below...
- <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
Correct.
Actually, I need to correct myself. Your examples have the new zpool
and vdev attribute on the <disk_name> element, not <disk>, so I assume
you wish it to remain on <disk_name>?
Yes. My mistake on that as well. <disk_name> is where the zpool and
vdev
attributes should go
- 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?
I would think we would have defaults for <zpool> attributes in a
similar way
we do now with action, name, is_root, mountpoint, zpool options,
dataset
options, etc.
?
Only action and is_root have default values, none of the others do.
What I'm asking is, if you have, say, the following in an AI manifest:
<target>
<disk>
<disk_name name="c2t2d2" name_type="ctd"/>
</disk>
<logical>
<zpool name="tank" action="create" is_root="true"/>
</logical>
</target>
should the app assume that disk "c2t2d2" is meant to belong in zpool
"tank"? Or must it be explicitly stated, eg:
<disk_name name="c2t2d2" name_type="ctd" zpool="tank"/>
For programming convenience, I prefer to make it explicit, but it might
certainly be easier for the user to make it optional.
I also prefer to make it explicit, but I'm unsure if it's the right
thing to do
for ease of use. Could get a couple of other folk's take on it.
I think this is pretty confusing without it being explicit. Without
the zpool tag its impossible to tell which pool the disk is in as well
as which disks the pool contains.
I am really just talking about the situation where there is exactly
one <zpool> in <logical> with 0 <vdev>s or there is exactly one <zpool>
in <logical> with exactly one <vdev> under it.
In this situation, is it reasonable to assume that any <disk> specified
should automatically belong to that zpool/vdev, without the user
having to explicitly link them?
Anyway, I think the answer is a resounding: "NO - it's too confusing!"
- Dermot
For example:
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd"/>
</disk>
<disk>
<disk_name name="c3t1d0" name_type="ctd"/>
</disk>
<disk>
<disk_name name="c4t0d0" name_type="ctd"/>
</disk>
<disk>
<disk_name name="c4t1d0" name_type="ctd"/>
</disk>
<logical>
<zpool name="rpool" action="create" is_root="true" />
<vdev name="rpool_mirror" redundancy="mirror"/>
</zpool>
<zpool name="tank" action="create" is_root="false" />
<vdev name="tank_mirror" redundancy="mirror"/>
</zpool>
</logical>
</target>
Without the zpool tag in the disk_name there isn't a way to tell which
disk is in which pool. It seems to me that we need this to be an error
if the pool isn't specified as part of the disk_name.
-evan
- Q: where do <swap> and <dump> go? under <target> or <logical>?
Honestly, I don't know yet. For Zvol based swap/dump, perhaps that
could be
an attribute to a <zvol> object which is a child under a <zpool>
object?
is_swap (true|false) "false" or something like that?
For UFS based ... I have no idea. Are we even supporting UFS
swap/dump?
I think I'm asking a simpler question: in the old schema, <dump> and
<swap>
are defined at the same level as <disk> and <zpool>:
<!ELEMENT target_device (disk|zpool+|swap|dump)>
Now that <zpool> is moving under the new <logical> element, should
<swap>
and <dump> also move under <logical> or should they remain at the
same level
as <disk>?
I'm not sure either, but I think <logical> is a better fit, as they
are not
"physical"
devices like <disk>s?
I think swap and dump should be attributes of a <zvol> element.
Something like
this:
<!ELEMENT zvol (options?, size) >
<!ATTLIST zvol action (create|delete|preserve|use_existing) "create">
<!ATTLIST zvol name CDATA #REQUIRED>
<!ATTLIST zvol is_swap (true|false) "false">
<!ATTLIST zvol is_dump (true|false) "false">
What do you think?
-Drew
_______________________________________________
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
