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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
