Sage Weil
2014-09-29 21:54:38 UTC
I took another look at the pull request for exposing tiers via librados[1]
and while it looks almost entirely correct, I'm not sure this is the
approach we should take. :( We expose all of this via the monitor API
(json commands to rados_mon_command() for via cli/rest/etc), so it is
awkward to replicate all of that via a low-level C API.
Intead, I think we should look to the minimal amount of metadata we need
to expose in order to get the job done (in this case, know which pools to
skip for the librbd check). After chatting with Josh he suggests
int64_t rados_get_base_tier(int64_t pool);
For a non-tiered pool, this would return pool. For a tiered pool, it
would return the pool that is logically associated with the data set...
the one you should read/write from.
I *think* that's sufficiently general that is should be future-proof to
whatever tiering changes we make later. Is there any tiering use-case
that would not be well-defined for? Or, are there other general questions
a librados-using app might be expected to need to know about tiering
topology? In general we want the tiering to be unnoticed by librados
users. Maybe whether we can expect a list_objects operation to return a
complete set? (This is one of the few portions of the librados API that
isn't papered over by tiering, although I suppose it could be.)
sage
[1] https://github.com/ceph/ceph/pull/2552
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
and while it looks almost entirely correct, I'm not sure this is the
approach we should take. :( We expose all of this via the monitor API
(json commands to rados_mon_command() for via cli/rest/etc), so it is
awkward to replicate all of that via a low-level C API.
Intead, I think we should look to the minimal amount of metadata we need
to expose in order to get the job done (in this case, know which pools to
skip for the librbd check). After chatting with Josh he suggests
int64_t rados_get_base_tier(int64_t pool);
For a non-tiered pool, this would return pool. For a tiered pool, it
would return the pool that is logically associated with the data set...
the one you should read/write from.
I *think* that's sufficiently general that is should be future-proof to
whatever tiering changes we make later. Is there any tiering use-case
that would not be well-defined for? Or, are there other general questions
a librados-using app might be expected to need to know about tiering
topology? In general we want the tiering to be unnoticed by librados
users. Maybe whether we can expect a list_objects operation to return a
complete set? (This is one of the few portions of the librados API that
isn't papered over by tiering, although I suppose it could be.)
sage
[1] https://github.com/ceph/ceph/pull/2552
--
To unsubscribe from this list: send the line "unsubscribe ceph-devel" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html