[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


--- 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
    * 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

    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