[Bugs] [Bug 1724089] New: ESTALE change in fuse breaks get_real_filename implementation

bugzilla at redhat.com bugzilla at redhat.com
Wed Jun 26 08:44:15 UTC 2019


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

            Bug ID: 1724089
           Summary: ESTALE change in fuse breaks get_real_filename
                    implementation
           Product: Red Hat Gluster Storage
           Version: rhgs-3.5
                OS: Linux
            Status: NEW
         Component: posix
          Severity: high
          Assignee: rabhat at redhat.com
          Reporter: anoopcs at redhat.com
        QA Contact: rhinduja at redhat.com
                CC: anoopcs at redhat.com, bugs at gluster.org,
                    gdeschner at redhat.com, madam at redhat.com,
                    rhs-bugs at redhat.com, sankarshan at redhat.com,
                    storage-qa-internal at redhat.com
        Depends On: 1723659, 1722977
  Target Milestone: ---
    Classification: Red Hat



+++ This bug was initially created as a clone of Bug #1723659 +++

+++ This bug was initially created as a clone of Bug #1722977 +++

Description of problem:

The change of ENOENT to ESTALE in the fuse bridge in
59629f1da9dca670d5dcc6425f7f89b3e96b46bf has broken the get_real_filename
implementation over fuse:

get_real_filename is implemented as a virtual extended attribute to help Samba
implement the case-insensitive but case preserving SMB protocol more
efficiently. It is implemented as a getxattr call on the parent directory with
the virtual key of "get_real_filename:<entryname>" by looking for a spelling
with different case for the provided file/dir name (<entryname>) and returning
this correct spelling as a result if the entry is found.

Originally (05aaec645a6262d431486eb5ac7cd702646cfcfb), the implementation used
the ENOENT errno to return the authoritative answer that <entryname> does not
exist in any case folding.

Now this implementation is actually a violation or misuse of the defined API
for the getxattr call which returns ENOENT for the case that the dir that the
call is made against does not exist and ENOATTR (or the synonym ENODATA) for
the case that the xattr does not exist.

This was not a problem until the gluster fuse-bridge was changed to do map
ENOENT to ESTALE in 59629f1da9dca670d5dcc6425f7f89b3e96b46bf, after which we
the getxattr call for get_real_filename returned an ESTALE instead of ENOENT
breaking the expectation in Samba.

(It is an independent problem that ESTALE should not leak out to user space but
is intended to trigger retries between fuse and gluster. My theory is that the
leaking happens because of the wrong use of ESTALE here: the parent directory
exists in this case, and there is nothing stale....) 

But nevertheless, the semantics seem to be incorrect here and should be
changed.


Version-Release number of selected component (if applicable):

master and version 6


How reproducible:

Always.


Steps to Reproduce:

On a gluster fuse mount, run `getfattr -n
glusterfs.get_real_filename:file-that-does-not-exist
/path/to/fuse/mount/some-subdir`.


Actual results:

This shows the ESTALE error.


Expected results:

It shows ENONET.

--- Additional comment from Worker Ant on 2019-06-22 03:31:05 IST ---

REVIEW: https://review.gluster.org/22925 ([RFC] change get_real_filename
implementation to use ENOATTR instead of ENOENT) posted (#1) for review on
master by Michael Adam

--- Additional comment from Michael Adam on 2019-06-22 03:33:50 IST ---

Corresponding changes to Samba are already written and will be posted to Samba.

--- Additional comment from Worker Ant on 2019-06-26 13:10:41 IST ---

REVIEW: https://review.gluster.org/22946 ([RFC] change get_real_filename
implementation to use ENOATTR instead of ENOENT) posted (#1) for review on
release-6 by Anoop C S


Referenced Bugs:

https://bugzilla.redhat.com/show_bug.cgi?id=1722977
[Bug 1722977] ESTALE change in fuse breaks get_real_filename implementation
https://bugzilla.redhat.com/show_bug.cgi?id=1723659
[Bug 1723659] ESTALE change in fuse breaks get_real_filename implementation
-- 
You are receiving this mail because:
You are on the CC list for the bug.


More information about the Bugs mailing list