On Friday, March 16, 2012 at 11:58 AM, Noah Watkins wrote: > > closedir does not explain what happens to the CephDirectory state under > > success and failure. Honestly I don't even know what you're supposed to do > > with it if it fails, and why the code resets it to PREPARING instead of a > > CLOSED state is unclear to me. :) > > > The motivation for closedir:success->PREPARING is that technically the > CephDirectory object could be re-opened (any clean-up associated with the > underlying struct ceph_dir_result is complete after closedir). On failure it > remains OPEN to prevent it from being re-opened. This is the same semantics > used for CephMount (re-mount is allowed only after a shutdown). Given the semantics we already have I think just putting them into a CLOSED (or FAULT) state and forcing people to create new objects is probably more sane and reasonable enough to do. But obviously don't bother if we do... > After some thought, I think there is a pretty simple way to avoid this whole > state-machine mess by enforcing state with the API and exceptions. For > example, CephDirectory:open should not exist to avoid even asking the > question 'can a CephDirectory be re-opened'. Valid states for CephDirectory > can be enforced by throwing an exception in CephMount:opendir (preventing > CephDirectory from being created), and some sane, documented semantics for a > closed CephDirectory can be added, such as returning null from > CephDirectory:getdnames. > > A similar approach to that of the Java 6 IO API can be taken for files in > Ceph by using a CephFile (ops over paths), CephFileInputStream, and > CephFileOutputStream (for opened files). > > I had originally not taken this path, instead valuing a close 1-1 mapping > between Java and libcephfs, but now I'm reconsidering. Do you have any > thoughts? Hrm. I've been in the C++ world for a long time! I guess probably following Java practices is the right answer for Java bindings though (and you seem to have started down that path already with CephDirectory). I wouldn't expect a real drop in functionality, and the increase in user clarity should be well worth the work? > > > If possible for my reviewing sanity, it'd be nice if I could access the > > changes you've made to things instead of trying to figure out how to run > > diffs against changing filenames and stuff, too, but that's just a wish. > > Sorry about this! I /really/ kicked myself after pushing that rebase for the > same reason... :(
Heh, thanks. :) -Greg -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
