librados: add map_object API #7749
Conversation
zhouyuan
force-pushed
the
librados_map_object
branch
2 times, most recently
from
12f0b1c to
2809667
Compare
| int up_primary, acting_primary; | ||
| o.pg_to_up_acting_osds(pgid, &up, &up_primary, &acting, &acting_primary); | ||
| string upsetstr(up.begin(), up.end()); | ||
| ldout(cct, 10) << "Object: " << obj_name << "up: " << upsetstr << ", p" << up_primary << dendl; |
There was a problem hiding this comment.
You don't nee dto use the intermediate strings... there is an operator<< overload for most stl containers so you can just print it directly.
There was a problem hiding this comment.
@liewegas thanks! will do in next rev.
|
I don't really like the string-based return type for the C version. We originally started doing this due to Colin's paranoia about different allocators being used by the calling code and by librados. Is that a real concern? Switching to int* and having the caller free seems easiest. Alternatively, the caller could provide a max buffer size and allocate the vector themselves. Or we could make a rados_intvector_free that looks just like ceph_buffer_free. Just using a user-allocated buffer and max_size seems the simplest, though... |
|
@jdurgin thoughts? |
zhouyuan
force-pushed
the
librados_map_object
branch
3 times, most recently
from
6ca08de to
7337d2b
Compare
|
@liewegas |
|
@jdurgin, care to look?
|
|
sure, and I just found a gh search operator (involves:username) so I don't lose track of this again |
| * @returns 0 on success, negative error code on failure | ||
| */ | ||
| CEPH_RADOS_API int rados_map_object(rados_t cluster, const char *obj_name, | ||
| char *up, size_t *up_size, |
There was a problem hiding this comment.
now that you're having the caller allocate them, is there any reason not to use int* instead of char* for up and acting?
There was a problem hiding this comment.
if you're calling this a lot, avoiding the string conversion will be more efficient too
There was a problem hiding this comment.
might want a version of this on IoCtx that reuses the locator (including namespace) set there
Ceph use crush algorithm to provide the mapping of objects to OSD servers.
However there's no public API for this instead you'll have to rely on the
command to monitor:
$ ceph osd map pool_name obj_name
The "ceph_get_osd_crush_location" method is made available via libcephfs
but not avaiale in librados.
This patch provides an API to render the object distribution layout in librados.
With this the application could choose which nodes to access, for load-balance
purpose.
The C++ API is:
map_object(const char *obj_name, std::vector<int>& up,
std::vector<int>& acting, int64_t pool_id)
The C API is:
CEPH_RADOS_API int rados_map_object(rados_t cluster, const char *obj_name,
int *up, size_t *up_size,
int *acting, size_t *acting_size,
int64_t pool_id);
With the new APIs we may get the data location(# of OSD) through the rados
instance.
Signed-off-by: Yuan Zhou <yuan.zhou@intel.com>
This patch adds the librados map_object API in python rados binding Signed-off-by: Yuan Zhou <yuan.zhou@intel.com>
zhouyuan
force-pushed
the
librados_map_object
branch
from
7337d2b to
a3e3116
Compare
|
@jdurgin |
|
@zhouyuan rados objects are mapped to pgs based on 'namespace', 'locator', and 'object name', which are all strings. An IoCtx in librados is stateful, and lets you set a namespace or locator to use for subsequent operations. |
|
Looking again, I think it would make sense to have only the IoCtx APIs, and not the plain Rados/rados_ ones. |
|
@jdurgin thanks for the quick review! I see your point now. Will move the APIs to IoCtx in next push. |
|
@zhouyuan ping |
Ceph use crush algorithm to provide the mapping of objects to OSD servers.
However there's no public API for this instead you'll have to rely on the
command to monitor:
$ ceph osd map pool_name obj_name
The "ceph_get_osd_crush_location" method is made available via libcephfs
but not avaiale in librados.
This patch provides an API to render the object distribution layout in librados.
With this the application could choose which nodes to access, for load-balance
purpose.
Signed-off-by: Yuan Zhou yuan.zhou@intel.com