(sorry for repost, vger was cranky about the first message) The code you are interested in is in src/rados_sync.cc. It would have been impossible to preserve rados object names fully, since they can be looong (it was either 2k or 4k, I forget), and most Linux local filesystems like ext3 can only hold 256 bytes in a single path component. The solution was to store the true name in an extended attribute of the locally exported file, and make the local name simply an approximation of that true name. If things get hairy, it appends a hash of the true name to the end of the mangled name. Rados import ignores the mangled names, and checks the truename stored in the user.rados_full_name xattr. Is this a complete solution? No. Two objects could have names that mangle to the same short name, and also have the same hash code. If you are interested in implementing the complete solution, simply use an incrementing counter rather than a hash. Another note. If these omaps you speak of are big, you are probably stuck using a separate file. Don't forget the rather short limits that ext3/ext4 puts on xattrs. It should be straightforward enough just to create a $FOO.omap for every $FOO. cheers, Colin On Mon, Apr 30, 2012 at 2:20 PM, Tommi Virtanen <tommi.virtanen@xxxxxxxxxxxxx> wrote: > > On Mon, Apr 30, 2012 at 14:08, Sage Weil <sage@xxxxxxxxxxxx> wrote: > >> Does just adding a .db suffix make the name safe? If yes, xattr is not > >> needed; if no, it's not enough. Reading src/rados_export.cc and > >> src/rados_sync.cc, I see nothing like that. What if I have objects > >> "foo" and "foo.db" in a pool? > > > > I'm pretty sure we need to mark the object with a magic xattr. Which > > probably means the filename itself needs to be mangled to avoid colliding > > with other objects. Probably an xattr on the object file referring to the > > external mangled file with the k/v content. > > Perhaps make the db file use one of the reserved characters that will > never appear in a plain old rados object. $ is the only one that's > really safe.. > > >> Note to self: the only thing avoiding collisions for e.g. "foo/" and > >> "foo$" is the hash. > > I vaguely recall Colin talking about the trailing /, but we may have > > decided to ignore the problem for now. > > Oh I mean anything that gets mapped to @ can cause collisions. "foo@" > and "foo$" will collide. "foo\n" and "foo\\" will collide. > > Frankly, my gut instinct right now is "kill it with fire". Collisions > in object names is a miserable problem to have. This would have been > better off with e.g. a HTTP-style %20 escaping mechanism, or a \x20 > style one; one that preserves the byte, and does not just replace it > with '@'. > -- > 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 -- 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
