From: Josh Durgin <jdurgin@redhat.com>
To: Jason Dillaman <dillaman@redhat.com>, Mykola Golub <mgolub@mirantis.com>
Cc: ceph-devel@vger.kernel.org
Subject: Re: CEPH_RBD_API: options on image create
Date: Wed, 14 Oct 2015 20:12:37 -0700 [thread overview]
Message-ID: <561F19A5.4080500@redhat.com> (raw)
In-Reply-To: <807360446.46582415.1444851292070.JavaMail.zimbra@redhat.com>
On 10/14/2015 12:34 PM, Jason Dillaman wrote:
> In general, I like the approach.
>
> I am concerned about passing a void* + length to specify the option value since you really can't protect against the user providing data in the incorrect format. For example, if the backend treated RBD_OPTION_STRIPE_UNIT as a 4byte int, what happens if someone passes a 2- or 8-byte int or a 4-byte char* string? Therefore, I would vote for passing strings a la librados rados_conf_set.
It seems like that'd be a bit clunky from C, since you'd need to create
and fill in buffers for each option.
For safety we could have typed rbd_image_options_{get,set} for char*
and uint64_t - it doesn't seem like we need any other types right now,
since uint64_t is a superset of what we use int for.
Another alternative is a single get/set that takes a tagged union, e.g.
struct rbd_image_option {
int option;
int type;
union {
uint64_t ui
int i
char* s // NUL-terminated
};
}
where type is an enum of RBD_OPTION_TYPE_{UINT64,INT,STRING} or similar.
> Perhaps rbd_create4 and rbd_clone3 should move the order and features options to rbd_image_options_t as well?
Sounds good - no reason to keep mandatory parameters for options with
defaults.
>> >Hi,
>> >
>> >It was mentioned several times eralier that it would be nice to pass
>> >options as key/value configuration pairs on image create instead of
>> >expanding rbd_create/rbd_clone/rbd_copy for every possible
>> >configuration override.
>> >
>> >What do you think about this API?
>> >
>> >Introduce rbd_image_options_t and functions to manipulate it:
>> >
>> >int rbd_image_options_create(rbd_image_options_t* opts);
>> >
>> >void rbd_image_options_destroy(rbd_image_options_t opts);
>> >
>> >int rbd_image_options_set(rbd_image_options_t opts, int optname,
>> > const void* optval, size_t optlen);
>> >
>> >int rbd_image_options_get(rbd_image_options_t opts, int optname,
>> > void* optval, size_t* optlen);
>> >
>> >void rbd_image_options_iterate(rbd_image_options_t opts,
>> > void (*func)(int* optname, void* optval,
>> > size_t* optlen));
>> >
>> >Functions that return a value return 0 on success, and -ERROR on
>> >failure.
>> >
>> >optname is a constant like RBD_OPTION_STRIPE_UNIT,
>> >RBD_OPTION_STRIPE_COUNT...
>> >
>> >Pass options as additional argument to rbd_create, rbd_clone (and may
>> >be rbd_copy) functions:
>> >
>> >int rbd_create4(rados_ioctx_t io, const char *name, uint64_t size,
>> > uint64_t features, int *order, rbd_image_options_t opts);
>> >
>> >int rbd_clone3(rados_ioctx_t p_ioctx, const char *p_name,
>> > const char *p_snapname, rados_ioctx_t c_ioctx,
>> > const char *c_name, uint64_t features, int *c_order,
>> > rbd_image_options_t opts);
>> >
>> >int rbd_copy3(rbd_image_t src, rbd_image_t dest, rbd_image_options_t opts);
>> >// possibly
I'm ambivalent about a copy3. If you'd like to implement it, it should
use the form that creates the destination image:
int rbd_copy3(rbd_image_t src, rados_ioctx_t dest_io_ctx,
const char *destname);
>> >
>> >
>> >Example:
>> >
>> >rbd_image_options_t opts;
>> >int r;
>> >r = rbd_image_options_create(&opts);
>> >assert(r == 0);
>> >uint64_t stripe_unit = 65536;
>> >r = rbd_image_options_set(opts, RBD_OPTION_STRIPE_UNIT,
>> > &stripe_unit, size_of(stripe_unit));
>> >assert(r == 0);
>> >uint64_t stripe_count = 16;
>> >r = rbd_image_options_set(opts, RBD_OPTION_STRIPE_COUNT,
>> > &stripe_count, size_of(stripe_count));
>> >assert(r == 0);
>> >const char* journal_object_pool = "journal";
>> >r = rbd_image_options_set(opts, RBD_OPTION_JOURNAL_OBJECT_POOL,
>> > journal_object_pool, strlen(journal_object_pool) +
>> > 1);
>> >assert(r == 0);
>> >r = rbd_create4(io, name, size, features, int *order, rbd_image_options_t
>> >opts);
>> >
>> >cleanup:
>> >rbd_image_options_destroy(opts);
I like the API in general. The ability to reuse the same options or
make small changes to them is nice.
Josh
next prev parent reply other threads:[~2015-10-15 3:11 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-09-30 6:50 CEPH_RBD_API: options on image create Mykola Golub
2015-10-14 19:34 ` Jason Dillaman
2015-10-15 3:12 ` Josh Durgin [this message]
2015-10-15 6:56 ` Mykola Golub
2015-10-15 6:33 ` Mykola Golub
2015-10-15 12:05 ` Jason Dillaman
2015-10-15 12:33 ` Mykola Golub
2015-10-15 12:47 ` Jason Dillaman
2015-10-15 13:28 ` Mykola Golub
2015-10-15 13:45 ` Sage Weil
2015-10-15 18:29 ` Josh Durgin
2015-10-16 5:32 ` Mykola Golub
2015-10-24 13:16 ` Mykola Golub
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=561F19A5.4080500@redhat.com \
--to=jdurgin@redhat.com \
--cc=ceph-devel@vger.kernel.org \
--cc=dillaman@redhat.com \
--cc=mgolub@mirantis.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.