I wanted to build on what Darren suggested but take a slightly different
course. I've always had issues with having to specify the
disk/slice/partition information twice (once in the <Disk> element and
again in the <Zpool> element).
Darren's suggestion (to use a reference ID) is a good one but I'd like
to expand on this. Currently the <Zpool> element is it's own
stand-alone element in which Vdev, Dataset, Filesystem, Zvol, Swap and
Dump objects can be configured.
What if we were to remove <Zpool> as the top level controller for these
elements and instead, introduce a <Logical> element?
Here's an example of what I'm trying to do
This is the current XML of my root disk on mox.us.oracle.com (where
rpool is). I have one partition and one slice. That one slice is given
entirely to rpool. (Trying to be concise, I didn't list all of the
datasets on my system ...)
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd"/>
<partition action="preserve" name="/dev/rdsk/c3t0d0p1" part_type="191">
<size val="585906615" start_sector="16065"/>
<slice name="/dev/dsk/c3t0d0s0" action="preserve" force="false">
<size val="585842355" start_sector="16065"/>
</slice>
<slice name="/dev/dsk/c3t0d0s2" action="preserve" force="false">
<size val="585874485" start_sector="0"/>
</slice>
<slice name="/dev/dsk/c3t0d0s8" action="preserve" force="false">
<size val="16065" start_sector="0"/>
</slice>
</partition>
</disk>
<zpool name="rpool" action="preserve" is_root="false">
<vdev redundancy="none">
<disk>
<disk_name name="c3t0d0" name_type="ctd"/>
<disk_prop dev_type="FIXED" dev_vendor="SEAGATE" dev_size="300000000000"/>
<disk_keyword key="boot_disk"/>
<slice name="/dev/dsk/c3t0d0s0" action="preserve" force="false">
<size val="585842355" start_sector="16065"/>
</slice>
</disk>
</vdev>
<dataset>
<filesystem name="rpool/ROOT/sol155" action="preserve"/>
</dataset>
<dataset>
<filesystem name="rpool/ROOT/sol156" action="preserve"/>
</dataset>
</target>
We all agree that having to specify the entire <Disk> node multiple
times is prone to failure. Unlike Darren's proposal, however, I'm
suggesting that for Physical elements (Disk, Partition or Slice), we add
an options "zpool" attribute to specify which zpool that particular
element belongs to. Inside the <Logical> tag, we can specify zpool
specifics like action, is_root?, redundancy, pool options and/or dataset
options.
The XML would use the "zpool" attribute from the Disk/Partition/Slice as
a reference attribute for a Zpool element name.
As an example, here's my rpool again, with my suggestions.
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd"/>
<partition action="preserve" name="1" part_type="191">
<size val="585906615" start_sector="16065"/>
<slice name="0" action="preserve" force="false" zpool="rpool">
<size val="585842355" start_sector="16065"/>
</slice>
</partition>
</disk>
<logical>
<zpool name="rpool" action="preserve" is_root="false" redundancy="none"/>
<filesystem name="/rpool/ROOT/sol155" action="preserve">
<filesystem name="/rpool/ROOT/sol156" action="preserve">
</logical>
</target>
To me, this is a cleaner approach both from the perspective of
manipulating the XML/DOC objects within CUD and as a user writing /
editing a manifest for AI to use.
Here's an example of creating more than a single zpool with more than 1
disk (I blanked out all the size values due to not wanting to actually
calculate those by hand :) ):
<target>
<disk>
<disk_name name="c3t0d0" name_type="ctd"/>
<partition action="create" name="1" part_type="191">
<size val="-" start_sector="-"/>
<slice name="0" action="create" force="false" zpool="rpool">
<size val="-" start_sector="-"/>
</slice>
<slice name="1" action="create" force="false" zpool="tank">
<size val="-" start_sector="-"/>
</slice>
</partition>
</disk>
<disk>
<disk_name name="c3t1d0" name_type="ctd" zpool="tank" />
</disk>
<disk>
<disk_name name="c3t2d0" name_type="ctd"/>
<partition action="create" name="1" part_type="-" zpool="code">
<size val="-" start_sector="-"/>
</partition>
<partition action="create" name="2" part_type="-" zpool="code">
<size val="-" start_sector="-"/>
</partition>
</disk>
<logical>
<zpool name="rpool" action="create" is_root="true" redundancy="none"/>
<zpool name="tank" action="create" is_root="false" redundancy="none"/>
<zpool name="code" action="create" is_root="false" redundancy="mirror"/>
<filesystem name="rpool/ROOT/sol155" action="create">
<filesystem name="rpool/ROOT/sol156" action="create">
<filesystem name="tank/slim_source" action="create">
<filesystem name="code/my_gate" action="create">
</logical>
</target>
c3t0d0 has one partition with slice 0 dedicated to rpool and slice 1
dedicated to the "rpool" zpool.
c3t1d0 is entirely dedicated to the "tank" zpool.
c3t2d0 has two partitions both dedicated to the "code" zpool
You'll notice there's also no reason to anchor the <Filesystem> or
<Zvol> elements to the <Zpool> because the name of the filesystem or
zvol already has the name of the zpool in it.
What do we think about something like this?
-Drew
On 1/12/11 8:12 AM, Darren Kenny wrote:
On 11/01/2011 11:16, Darren Kenny wrote:
On 07/01/2011 23: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.
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.
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 would specify a mirror made from c0t0d0s0 and c0t0d1p3.
Alok, Drew and I would like to nail this down by Jan 14th.
Hi Jean/Alok/Drew,
While I totally understand the purpose of this, I really would prefer if thing
made better use of XML here rather than free-text, specifically w.r.t. the text:
disk ="c0t0d0" slice = "0"
disk ="c0t0d1" part = "3"
I think you should use a specific child-tag of<vdev> here to allow for some
enforcement of the specification in the XML, and also to perform some basic
syntax checking automatically.
As such, maybe it's worth having a<dev> tag like:
<vdev redundancy="mirror">
<dev disk ="c0t0d0" slice = "0"/>
<dev disk ="c0t0d1" part = "3"/>
</vdev>
Maybe since this is in essence a reference to a device that needs to be
specified else where (using<disk>, etc) then maybe it should be called
<dev_ref> or<vdev_ref> - so that it's obvious that it's a reference.
I just think that if we're using XML we shouldn't be allowing free-text unless
there is absolutely no other option to handle things that way - and in this case
I thing XML is a good way to specify things.
Just to add to this, I don't think we can limit things to the use of the ctd
naming - mainly since we allow disk selection to be done without knowing this.
For example, you could decide to select based on the bootdisk, and define some
partitions and slices on it. In this case you don't know the ctd of the disk,
but you do know the slices indexes:
<!-- Define Physical Disk layout -->
<target_device>
<disk>
<disk_keyword key="boot_disk"/>
<slice name="0"></slice>
<slice name="1"></slice>
</disk>
</target_device>
<!-- Define Logicial devices -->
<target_device>
<zpool name="rpool" is_root=true>
<vdev>
<dev_ref slice="0"/>
</vdev>
<zpool>
</target_device>
<target_device>
<zpool name="space" is_root=false>
<vdev>
<dev_ref slice="1"/>
</vdev>
<zpool>
<target_device>
If you do this, specifying a slice, with out the disk name, would fall back to
the selected disk.
Because of this, I feel there is a need to be able to concretely identify a disk
that a slice is on, and I feel this could be done using an attribute such as
'id' which uniquely identifies the disk, regardless of the selection criteria
for the disk, e.g.
<!-- Define Physical Disk layout -->
<target_device>
<disk id="my_disk"> <!-- Can be anything for id as long as it's unique -->
<disk_keyword key="boot_disk"/>
<slice name="0"></slice>
<slice name="1"></slice>
</disk>
</target_device>
<!-- Define Logicial devices -->
<target_device>
<zpool name="rpool" is_root=true>
<vdev>
<dev_ref id="my_disk" slice="0"/>
</vdev>
<zpool>
</target_device>
<target_device>
<zpool name="space" is_root=false>
<vdev>
<dev_ref id="my_disk" slice="1"/>
</vdev>
<zpool>
<target_device>
Just a suggestion ;)
Thanks,
Darren.
_______________________________________________
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
