Hi Drew,
Interesting way of looking at things - but - while this does work, there is a
gap in there, where you can have multiple <vdevs> under the <zpool>:
<zpool>
<vdev redundency="mirror">
<device_ref .. />
<device_ref .. />
</vdev>
<vdev redundency="mirror">
<device_ref .. />
<device_ref .. />
</vdev>
<vdev redundency="spare">
<device_ref .. />
<device_ref .. />
</vdev>
</zpool>
Unfortunately I think this would be too difficult to achieve using your
approach.
Ultimately what you are proposing here is not that dissimilar to the idea of
adding an 'id' attribute - just yours is called 'rpool' ;)
I still think that the way of defining the physical and logical devices
separately, is more 'natural' and like how an admin might do it using
command-lines, e.g.:
fdisk ....
format ...
zpool create ...
I do understand that the notion of references isn't ideal, but I think it's
easily understood once explained & documented.
Thanks,
Darren.
On 14/01/2011 11:14, Matt Keenan wrote:
> Definitely a different take on the referencing, and does solve the problem of
> having to specify target information in two locations.
>
> Going down this route would be mean major surgery being done to the existing
> schema as delivered in Solaris Express, is this something we want to do ? I
> know
> we are going to make changes either way but just wondering do we want to
> minimize these.
>
> One comment further down.
>
> On 01/13/11 11:16 PM, Drew Fisher wrote:
>> 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>
>>
>>
>
> should is_root for "rpool" not be true ?
>
>> 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>
>>
>
> In above example you specify Slice 0 of disk c3t0d0 being in zpool "rpool" yet
> you specify slice 1 of the same disk being part of zpool "tank", is this a
> typo
> or intentional, as I'm not even sure this is possible.
>
> If zpool atttribute is omitted from any one of the targets would it default to
> "rpool" (or whatever the name is given to the root pool, as specified in
> <logical> section)
>
> What if zpool attribute on a <disk> differs from a zpool attribute on a chlld
> <partition> or <slice> ?, guessing this should not be allowed, e.g. if zpool
> specified at disk level, it would override all other zpool attributes that
> might
> be specified on it's children.
>
> Under <logical> would it be a requirement to always have at least one <zpool>
> where is_root="true" ?
>
> All zpool attributes specified on target "Must" exist as <zpool>'s in
> <logical>
> ? (and only once).
>
> I can definitely see the merits of this proposal.
>
> cheers
>
> Matt
>
>>
>> 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.
>>
>
> So to specify a zvol you'd just specify something like the following directly
> under <logical>
> <zvol name="tank/spare_swap" action="create>
> <size val="100gb"/>
> </zvol>
>
>
>> 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
>
>
>
> _______________________________________________
> 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
