[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:04:15 UTC 2017


Raghavendra G <rgowdapp at redhat.com> changed:

           What    |Removed                     |Added
             Status|NEW                         |ASSIGNED

--- Comment #3 from Raghavendra G <rgowdapp at redhat.com> ---
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.

>From kernel source code fs/namei.c:


        filp = path_openat(&nd, op, flags | LOOKUP_RCU);
        if (unlikely(filp == ERR_PTR(-ECHILD)))
                filp = path_openat(&nd, op, flags);

        if (unlikely(filp == ERR_PTR(-ESTALE)))           <==== NOTE HERE
                filp = path_openat(&nd, op, flags | LOOKUP_REVAL);


However that this hypothesis is _VALID ONLY IF_ kernel doesn't maintain the
atomicity  of (lookup + open) in do_sys_open. If it is not maintaining
atomicity, but instead relying on ESTALE error, this could be solved by passing
back ESTALE as the error when we find that gfid is missing.

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