[Bugs] [Bug 1500269] opening a file that is destination of rename results in ENOENT errors
bugzilla at redhat.com
bugzilla at redhat.com
Tue Oct 17 05:14:45 UTC 2017
https://bugzilla.redhat.com/show_bug.cgi?id=1500269
--- Comment #8 from Worker Ant <bugzilla-bot at gluster.org> ---
COMMIT: https://review.gluster.org/18463 committed in master by Raghavendra G
(rgowdapp at redhat.com)
------
commit 019a55e708375d2b1e576fcc948a691bcdc5c749
Author: Raghavendra G <rgowdapp at redhat.com>
Date: Tue Oct 10 11:29:04 2017 +0530
Revert "mount/fuse: report ESTALE as ENOENT"
This reverts commit 26d16b90ec7f8acbe07e56e8fe1baf9c9fa1519e.
Consider rename (index.new, store.idx) and open (store.idx) being
executed in parallel. When we break down operations following sequence
is possible.
* lookup (store.idx) - as part of open(store.idx) returns gfid1 as the
result.
* rename (index.new, store.idx) changes gfid of store.idx to
gfid2. Note that gfid2 was the nodeid of index.new. Since rename is
successful, gfid2 is associated with store.idx.
* open (store.idx) resumes and issues open fop to glusterfs with
gfid1. open in glusterfs fails as gfid1 doesn't exist and the error
returned by glusterfs to kernel-fuse is ENOENT.
* kernel passes back the same error to application as a result to
open.
This error could've been prevented if kernel retries open with
gfid2. Interestingly kernel do retry open when it receives ESTALE
error. Even though failure to find gfid resulted in ESTALE error,
commit 26d16b90ec7f8acb converted that error to ENOENT while sending
an error reply to kernel. This prevented kernel from retrying open
resulting in error.
Change-Id: I2e752ca60dd8af1b989dd1d29c7b002ee58440b4
BUG: 1500269
Signed-off-by: Raghavendra G <rgowdapp at redhat.com>
--
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