| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The bug referenced in this change, had an race condition that is now
fixed by the following commits that are posted for review.
http://review.gluster.org/#/c/8563/
http://review.gluster.org/#/c/8570/
These changes would now make the winning client not fail a rename,
in case it failed to rename the linkto file. Hence when one client
wins the link race, and the other still deletes the linkto file,
the rename failure by the winning client is not a critical failure,
hence it resolves the issue posted in the bug.
As a result modifying the test case to treat the rename failures
as errors, to catch any future issues.
Change-Id: Ibe9caac7ee87dcbc4f581cfbd36173b734859ccb
BUG: 1123950
Signed-off-by: Shyam <srangana@redhat.com>
Reviewed-on: http://review.gluster.org/8579
Reviewed-by: Jeff Darcy <jdarcy@redhat.com>
Tested-by: Gluster Build System <jenkins@build.gluster.com>
Reviewed-by: Vijay Bellur <vbellur@redhat.com>
|
|
|
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>
|
