On Fri, Feb 25, 2011 at 12:24 PM, Colin Patrick McCabe <colin.mccabe@xxxxxxxxxxxxx> wrote: > On Fri, Feb 25, 2011 at 11:48 AM, Sage Weil <sage@xxxxxxxxxxxx> wrote: >> We're definitely moving into bikeshedding territory now, but one thing >> Yehuda suggested: >> >> The pool handle (rados_pool_t, PoolHandle) has state associated with it, >> including the snap to read from or snap context to write with. That's not >> obvious from the name. Maybe it should be renamed rados_ioctx_t to be >> more clear. Then the pool we're reading to/writing from becomes one more >> piece of state associated with the handle. > > PoolHandle in the C++ API and pool_t in the C API map onto > RadosClient::PoolCtx, which contains the aforementioned state. So if > we change this in the C++ API, we should change it all the way > through, and rename pool_t, RadosClient::PoolCtx, etc. > > Should we? I could go either way. The concept of a handle itself > having properties is not really unfamiliar. After all, two different > processes can open two different file descriptors referring to the > same file, but one with O_RDONLY, and the other with O_WRONLY. etc. A > handle to a thing is not the same as the thing itself. > But in the case of two different files, it is clear that you're opening a specific file. A pool handle is similar to a file, however, when you're using a file handle you can write to a specific file, whereas with a pool handle you can (though not necessarily supposed to) write to different objects. That is, a pool is more of a partition than a single file, so the analogy is not quite right. The pool handle should only be used with objects that share the same context, but there's nothing in the infrastructure that prevents users to misuse it, and the penalty for using the wrong snap context can be very high (loss of data). Yehuda -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
