Drew,
A couple of follow on points below...
On 01/18/11 16:22, Drew Fisher wrote:
Dermot,
On 1/18/11 7:53 AM, Dermot McCluskey wrote:
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?
I will start working on this after I get Dave's buy-off on the 3 use
cases. I will certainly need help with it!
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)?
For now, ignore the is_root attribute. I contemplated leaving it out
of my example use cases so as not to confuse and now I wish I had.
:) The default value for is_root in the current schema is "false" so
that's what I put in here.
ok
<!-- 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?
Yes. Python force of habit! These are just dictionaries, right? :)
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?
I was thinking that the action attribute will still apply to the
<zpool> tag. If the attribute is use_existing or preserve, I wouldn't
presume to destroy the old zpool. There probably needs to be some
checks in the target code to ensure that the vdevs listed in a pool
with an action of "preserve" or "use_existing" actually match up though.
So, my (partial) summary of the changes to the DTD is as follows:
- <target_device> is being dropped
I see no reason for this element. It's currently an empty element and
provides little.
agreed
- <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>)
Correct.
- <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>?
- 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.
- <target> is getting a new, optional, sub-element: <logical>
Correct.
- the sub-elements of <logical> are 1 or more <zpool> elements
Correct.
- 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?
- Dermot
- <vdev> now has no sub-elements
Correct.
-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
