[stgt] backing-store options

[Dan Mick]

On 10/03/2013 04:17 PM, Boaz Harrosh wrote:
> On 10/03/2013 04:06 PM, Dan Mick wrote:
>> For bs_rbd, I need to pass some options through from tgtadm.  I don't
>> see a generic mechanism for doing this; there's
>>
>> * bsoflags, which seems to be an int with O_ flags in it, and
>>
>> * --params, but those seem specific to --op update and disallowed for
>> OP_NEW (and have predefined meanings anyway).
>>
>> Anyone have any objection to a --bsopts parameter that is free-form and
>> interpreted only by the selected backend storage driver?  This would go
>> with --backing-store and --bstype and --bsoflags.
>>
>> (I'm not sure what a good short option letter would be; 'S' is one of
>> the few available.)
>>

> What I did as a QD is use the --backing-store string with a ":" for
> separating parameters in the form:
>
> old --backing-store
> 	/path/to/exported/object/stor/
> (Which is just a directory on disk to hold the object store)
> New --backing-store
> 	/path/to/exported/object/stor/:param_foo=some_value:param_baz=some_other_value
>
> And so on. So I did not need to change any tgtd core code, and the sig of my bs_osdemu
> need not change. The parsing of such string is trivial. All params are optional
> so the code is backward compatible

Yeah, that's always an option, but it's somewhat cumbersome; we did that 
for a while with the rbd extensions to qemu, but they were pretty much 
universally hated.  I think an option string is cleaner.  But I'm not 
adamant.  Any other opinions?  (I have a prototype implementation; the 
changes are small and obvious; end up in one new parameter to
(*bs_init)(lu, bsopts))


--
To unsubscribe from this list: send the line "unsubscribe stgt" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html