]> git-server-git.apps.pok.os.sepia.ceph.com Git - ceph.git/commit
os/LFNIndex: handle long object names with multiple links (i.e., rename)
authorSage Weil <sage@redhat.com>
Sat, 19 Jul 2014 00:09:07 +0000 (17:09 -0700)
committerSage Weil <sage@redhat.com>
Wed, 23 Jul 2014 21:48:14 +0000 (14:48 -0700)
commitb2cdfce6461b81f4926602a8c63b54aa92684e6c
treeb01890b6a0831b5fc1db798349a073be4d944c6a
parentcf98805c09a38cce78ac08317899dc4152ae55a5
os/LFNIndex: handle long object names with multiple links (i.e., rename)

When we rename an object (collection_move_rename) to a different name, and
the name is long, we run into problems because the lfn xattr can only track
a single long name linking to the inode.  For example, suppose we have

foobar -> foo_123_0 (attr: foobar) where foobar hashes to 123.

At first, collection_add could only link a file to another file in a
different collection with the same name. Allowing collection_move_rename
to rename the file, however, means that we have to convert:

col1/foobar -> foo_123_0 (attr: foobar)

to

col1/foobaz -> foo_234_0 (attr: foobaz)

This is a problem because if we link, reset xattr, unlink we end up with

col1/foobar -> foo_123_0 (attr: foobaz)

if we restart after we reset the attr.  This will cause the initial foobar
lookup to since the attr doesn't match, and the file won't be able to be
looked up.

Fix this by allow *two* (long) names to link to the same inode.  If we
lfn_link a second (different) name, move the previous name to the "alt"
xattr and set the new name.  (This works because link is always followed
by unlink.)  On lookup, check either xattr.

Don't even bother to remove the alt xattr on unlink.  This works as long
as the old name and new name don't hash to the same shortname and end up
in the same LFN chain.  (Don't worry, we'll fix that next.)

Fixes part of #8701
Signed-off-by: Sage Weil <sage@redhat.com>
src/os/LFNIndex.cc
src/os/LFNIndex.h