[Stgt-devel] [PATCH] tgt-admin: support persistent device binding

[FUJITA Tomonori]

On Tue, 29 Jul 2008 13:21:45 +0200
Tomasz Chmielewski <mangoo at wpkg.org> wrote:

> FUJITA Tomonori schrieb:
> > On Tue, 29 Jul 2008 13:51:55 +0300
> > Doron Shoham <dorons at Voltaire.COM> wrote:
> > 
> >> Eli Dorfman wrote:
> >>>>> maybe use the following format :
> >>>>> <target xyz>
> >>>>>     <backing-store /dev/sdb>
> >>>>>           properties  custom # use properties specified below or
> >>>>> default (generate the deadbeaf id) or direct (get real serial number)
> >>>>>           serial-number 12345678
> >>>>>           vendor myvendor
> >>>>>     </backing-store>
> >>>>> </target>
> >>>>>
> >>>>> what do you think?
> >>>> Hmm, 'properties custom' looks unnecessary for me. If a device file of
> >>>> a disk drive is used as backing-store and none of the properties are
> >>>> specified, we can use the physical properties.
> >>> we need something like properties to differentiate between disk (read
> >>> real props), file (generate unique serial number
> >>> disk-sn-partition-filename) and custom (applicable to any case).
> >>> we can call this attribute: "type" which can accept 3 values disk,
> >>> file or custom (default).
> >> This is what I suggest:
> >>
> >> <target iqn.2007-04.com.example:san.monitoring>
> >>    <backing-store /tmp/ramdisk/lun1>
> >>       type default
> >>       serial 12345678
> >>       vendor my_vendor
> >>       product_id my_id
> >>       product_rev my_rev
> >>    </backing-store>
> >>
> >>    <backing-store /dev/sdc>
> >>       type disk
> >>    </backing-store>
> >> </target>
> >>
> >> The reason we use XML is that the original implementation used XML.
> >>
> >> We suggest two types:
> >> 1. disk: "real" physical devices, where we read the properties from the device itself - i.e. storage disks.
> >> 2. default - use default tgt values. 
> >>    We can also override the properties with user defined values (optional).
> >>
> >> The reason for the type attribute is to differentiate between these two types.
> > 
> > I don't know anything about XML but should it be something like?
> > 
> > <target iqn.2007-04.com.example:san.monitoring>
> >    <lun 0>
> >      type sbc
> >      backing-store
> 
> What we use currently in tgt-admin is a mix of XML and a flat config file, I would say.
> With the benefits of both (easy hand editing; it is clear where one target definition starts and where it ends).
> 
> 
> If it was "proper XML", it should look like:
> 
> <target iqn.2007-04.com.example:san.monitoring>
> 	<lun 0>
> 		<type sbc />
> 		<backing-store />
> 	</lun>
> </target>
> 
> Which is not that nice for hand editing anymore - forget one slash
> in one place (i.e., after "type sbc"), and your whole config file is
> invalid.

But it would be better to let administrators not to edit a
configuration file by hand? And I guess that using a pure XML enables
us to use perl XML libraries? I thought that that's the reason why
people want to use XML.

IMHO, it's much easier to edit a plain text file rather than a XML
file.

> However this one still looks OK and makes sense I would say, if we want to precisely configure different luns?
> 
>  <target iqn.2007-04.com.example:san.monitoring>
>     <lun 0>
>       type sbc
>       backing-store

I think that it would be better to have a configuration format that
can describe everything.