[Bugs] [Bug 1452084] New: [Ganesha] : Stale linkto files after unsuccessfuly hardlinks

[bugzilla at redhat.com]

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

            Bug ID: 1452084
           Summary: [Ganesha] : Stale linkto files after unsuccessfuly
                    hardlinks
           Product: GlusterFS
           Version: mainline
         Component: distribute
          Assignee: jthottan at redhat.com
          Reporter: jthottan at redhat.com
                CC: bugs at gluster.org, rhs-bugs at redhat.com,
                    storage-qa-internal at redhat.com, tdesala at redhat.com



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

Description of problem:


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

How reproducible:
if cache and hash subvolme of hardlink is different

Steps to Reproduce:
Run link/00.t test from posix testsuite(pjdtest suite) on nfs clients using
ganesha

 Steps executed in script
     * create a file "abc" using root
     * create hardlink "link" for "abc" using a non root user, it fails with
EACESS
     * delete "abc"
     * create directory "abc" using root
     * again try to create hadrlink "link" for "abc" using non root user, fails
with ESTALE

Actual results:
Fails with ESTALE

Expected results:
Fail with EACESS

Additional info:
This is a similar issue fixed for rename in
https://review.gluster.org/#/c/16016/
    For hardlinks, if cached and hashed subvolumes are different, then it will
first create linkto file in hashed using root permission, but actually hardlink
creation fails with EACESS and stale linkto file is never removed. All the
followup hardlink calls with file name will result ESTALE due to that linkto
file.
In the code mknod call for the linkto('T')[as part of dht_link] fails with
EEXIST and following lookup results in ESTALE

Thanks Susant for the help in RCAing above issue

-- 
You are receiving this mail because:
You are on the CC list for the bug.
Unsubscribe from this bug https://bugzilla.redhat.com/token.cgi?t=NWXr3DkcZS&a=cc_unsubscribe