[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

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:

<do_filep_open>

        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);

</do_filep_open>

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.