summaryrefslogtreecommitdiffstats
path: root/xlators/cluster/dht/src/dht-common.c
diff options
context:
space:
mode:
authorJeff Darcy <jdarcy@redhat.com>2014-07-08 21:56:04 -0400
committerVijay Bellur <vbellur@redhat.com>2014-07-17 10:30:56 -0700
commit950f9d8abe714708ca62b86f304e7417127e1132 (patch)
tree29cf61da19955ff9d694025360c332bcbb6ca7f3 /xlators/cluster/dht/src/dht-common.c
parent8896ffd86b1856de17d65874f89a76ad84b6258b (diff)
dht: fix rename race
If two clients try to rename the same file at the same time, we sometimes end up with *no file at all* in either the old or new location. That's kind of bad. The culprit seems to be some overly aggressive cleanup code. AFAICT, based on today's study of the code, the intent of the changed section is to remove any linkfile we might have created before the actual rename. However, what we're removing might not be our extra link. If we're racing with another client that's also doing a rename, it might be the only remaining link to the user's data. The solution, which is good enough to pass this test but almost certainly still not complete, is to be more selective about when we do this unlink. Now, we only do it if we know that, at some point, we did in fact create the link without error (notably ENOENT on the source or EEXIST on the destination) ourselves. Change-Id: I8d8cce150b6f8b372c9fb813c90be58d69f8eb7b BUG: 1117851 Signed-off-by: Jeff Darcy <jdarcy@redhat.com> Reviewed-on: http://review.gluster.org/8269 Tested-by: Gluster Build System <jenkins@build.gluster.com> Reviewed-by: Vijay Bellur <vbellur@redhat.com>
Diffstat (limited to 'xlators/cluster/dht/src/dht-common.c')
0 files changed, 0 insertions, 0 deletions