]> 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)
committerSamuel Just <sam.just@inktank.com>
Sun, 3 Aug 2014 19:47:10 +0000 (12:47 -0700)
commitcbfbe637851c7ebe4a9ec1fd6e429cdf85aef608
treec5eebecc48c9227bb45edd8dd3a3f88b9c7505cb
parent5db6c12b61e00b0bc8084ead5976a912ece0fc65
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>
(cherry picked from commit b2cdfce6461b81f4926602a8c63b54aa92684e6c)
src/os/LFNIndex.cc
src/os/LFNIndex.h