Drew,
On 01/27/11 15:32, Drew Fisher wrote:
Dermot,
Comments in-line ...
19 CDDL HEADER END
20
21 Copyright (c) 2011, Oracle and/or its affiliates. All rights
reserved.
Nit: shouldn't this be "Copyright (c) 2010, 2011, Oracle ..." ?
Fixed.
22
23 -->
24
25 <!ELEMENT target (disk+, logical*)>
Sorry not to mention this earlier, but I have another question:
Is it possible that the user might want to the write a manifest
where they don't specify *any* details of specific disks or zpools,
but only want to say that there should be no swap or no dump
used? ie:
<target>
<logical noswap="true" nodump="true"/>
</target>
If this is a legitimate thing we want to allow the user to specify,
then we would need to change "disk+" to "disk*". However, I don't
like doing this as it might lead the user to think they can specify
<logical> without specifying and <disk>s, which would be a
semantic error.
I think Sanjay commented on this one.
26
27 <!ELEMENT disk ((disk_name|disk_prop|disk_keyword|iscsi),
partition*, slice*)>
28 <!--
29 in_zpool and in_vdev are reference attributes to a
30 corresponding <zpool> name and <vdev> name under the
<logical>
31 element. This is how physical elements are linked with
logical
32 entires.
33
34 The values of the in_zpool and in_vdev attributes, if
given, must
35 exactly match the name attributes of a zpool or vdev.
36 If one or both of these attributes are specified, it must be
37 possible to uniquely identify a zpool or vdev from them.
You took one of my suggested comments here, but not the other, which
is fine, but don't you want to say something about how if you specify
in_zpool and/or in_vdev on a disk, partition or slice then you must not
also specify either of those attributes on the parent object (disk or
partition)?
With all the emails flying on this, I missed your comment on it. I
found it and added it in.
54 <!--
55 dev_size must be number suffixed with a size unit. i.e
100gb
Nit: s/i.e/e.g./ ?
Fixed.
77
78 <!ELEMENT partition (partition*, slice*, size?)>
As per your other email, this will change to
<!ELEMENT partition (slice*, size?)>
Yep. Fixed.
115 <!--
116 The 'val' attribute of Size must be suffixed with a size
unit.
117 i.e 100gb, 2secs, 2tb.
Nit: s/i.e/e.g./
Fixed.
135 <!ELEMENT logical (zpool+)>
Did we get agreement that the above should be changed
to "zpool*" to allow for the case where the user wants to
specify noswap or nodump, but does not want to specify
any specific zpool details?
I honestly don't know.
136 <!ATTLIST logical noswap (true|false) "false">
137 <!ATTLIST logical nodump (true|false) "false">
138
139 <!--
140 If zpools and/or vdev are specified, then they must be
associated
141 with disk_names, partitions or slices via the use of the
in_zpool
142 and/or in_vdev attributes of those elements, described
above.
143 -->
144 <!ELEMENT zpool (vdev*, filesystem*, zvol*, pool_options?,
dataset_options?, be?)>
Question: can there only be a max of 1 BE under a zpool ("be?")?
Or can there be multiples ("be*")?
I changed it to be* based on the way TD finds all BEs on the system.
I think my question was badly worded:
The DTD is more related to what we are allowing the user
to specify in the AI or DC manifests, not what we need to
store internally when TD is run.
So, do we want to allow the user to specify multiple <BE>s under
a <zpool> in the manifest?
- Dermot
145 <!ATTLIST zpool name CDATA #REQUIRED>
146 <!ATTLIST zpool action (create|delete|preserve|use_existing)
"create">
147 <!ATTLIST zpool is_root (true|false) "false">
148 <!ATTLIST zpool mountpoint CDATA #IMPLIED>
149
150 <!--
151 The vdev name is purely used for matching the value of
the in_vdev
152 attribute on disk, partitions or slices.
Nit: s/disk/disks/ ???
Fixed.
Newest one is in cud_ti and attached here.
-=
------------------------------------------------------------------------
------------------------------------------------------------------------
_______________________________________________
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
