[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 10 10:09:36 UTC 2017


--- Comment #4 from Raghavendra G <rgowdapp at redhat.com> ---
To verify the hypothesis I made following fixes

* reverted [1]
* converted ENOENT error to ESTALE in fuse_fd_cbk as open is an operation on
gfid and correct error for a missing gfid is ESTALE. Note that some cases brick
can return ENOENT for missing gfid. This can happen if resolver in
protocol/server successfully resolves gfid, but the fop (open in this example)
fails in storage/posix due to gfid-handle missing in .glusterfs

On applying these two fixes and rerunning the above test - open and rename.sh
in infinite loop in parallel on the same mount - I was not able to hit the

However if I run open and rename (c program), the issue is reproducible even
with fixes. The explanation I could come up with is that,
* Kernel retries only once on getting an ESTALE error during open (as can be
seen in do_filep_open code in kernel VFS)
* Binary "rename" generated by C program is fast enough that it could do more
than one rename in the window of single "open".

This explanation is bit counter intuitive given that the program rename has two
syscalls and the program open has one syscall. But, that's the best explanation
I can come up with for now.

[1] http://review.gluster.org/13816

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