[Bugs] [Bug 1378550] Moving multiple temporary files to the same destination concurrently causes ESTALE error
bugzilla at redhat.com
bugzilla at redhat.com
Mon Oct 17 11:09:14 UTC 2016
https://bugzilla.redhat.com/show_bug.cgi?id=1378550
Raghavendra G <rgowdapp at redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
Assignee|bugs at gluster.org |khiremat at redhat.com
--- Comment #2 from Raghavendra G <rgowdapp at redhat.com> ---
(In reply to Pranith Kumar K from comment #1)
> Du, Nitya,
> Based on my debugging inodelk keeps failing with ESTALE. When I
> checked dht_rename(), I see that the inodelk is done both on source and
> destination inodes. But because the test above can lead to deletion of the
> file we are trying to lock on by the other 'while ()...' process the inodelk
> fails with ESTALE. When I changed the test to rename to independent
> filenames, then everything works as expected.
> On mount1:
> while true; do uuid="`uuidgen`"; echo "some data" > "test$uuid"; mv
> "test$uuid" "test" -f; done
>
> On mount2:
> while true; do uuid="`uuidgen`"; echo "some data" > "test$uuid"; mv
> "test$uuid" "test2" -f; done
>
> Not sure how to fix this in DHT though. For now re-assigning the bug to DHT.
locking in dht_rename has two purposes:
1. serialize and ensure atomicity (of each rename) when two parallel renames
are done on the same file.
2. serialize a rename with file migration during rebalance.
The current use-case falls into category 1. I think using entrylk instead of
inodelk solves the problem. However need to think more about this.
Assigning bug to Kotresh as he is working on synchronization issues.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
More information about the Bugs
mailing list