[Bugs] [Bug 1500269] opening a file that is destination of rename results in ENOENT errors

[bugzilla at redhat.com]

https://bugzilla.redhat.com/show_bug.cgi?id=1500269



--- 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
issue.

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.