Yehuda and I talked about the lfn branch today and we're not on the same page yet about the best way to proceed. The current code keeps the long file name translating independent of the other naming/mangling that FileStore does (collection/ prefix, escaping, and sobject_t -> <object>_<snapid|head>). I see that it's nice to do one thing at once, but I'm also not sure the long files are useful anywhere else. Other thoughts: The escaping may make more sense in the same layer as the long name stuff? Eventually we'll be prehashing the pg dir contents into subdirs, and that translation will have to be done somewhere too. That will mean possibily looking in two locations during the rehashing process, similar to how the lfn stuff has to peek at xattrs. One thing to keep in mind is that the hash value will need to be passed down and stored with the file... it's usually hash(object name), but not always when the object_locator_t::key is set. Where will this fit in? We may eventually want to adjust the ObjectStore interface to include collection/dir handles so that the full path isn't traversed in kernel for every operation (the OSD could maintain an open handle/fd for each pg it has open). I think the lfn_open/_get type interface below all of the operation methods will allow all of those things. I think it'll be simpler to push as much of the filename rendering into that layer as possible, though (possibly including the sobject_t mangling). Having all the mangling/rendering done in one place will also make it easy to extend without making multiple passes in different layers... Unfortunately I'm out tomorrow. Any other opinions? One other thing: the xattr names are mangled too (user.ceph. prefix). As long as the long name xattr has a different prefix we don't have to worry about those getting mixed up. sage -- 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
