Bug 1452084

Summary:	[Ganesha] : Stale linkto files after unsuccessfuly hardlinks
Product:	[Community] GlusterFS	Reporter:	Jiffin <jthottan>
Component:	distribute	Assignee:	Jiffin <jthottan>
Status:	CLOSED CURRENTRELEASE	QA Contact:
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	mainline	CC:	bugs, nbalacha, pasik, rhs-bugs, storage-qa-internal, tdesala
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.12.0	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1452083	Environment:
Last Closed:	2017-09-05 17:30:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Jiffin 2017-05-18 10:16:57 UTC

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

Comment 1 Worker Ant 2017-05-18 10:17:54 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#1) for review on master by jiffin tony Thottan (jthottan)

Comment 2 Worker Ant 2017-06-07 05:39:47 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#2) for review on master by jiffin tony Thottan (jthottan)

Comment 3 Worker Ant 2017-06-07 05:42:33 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#3) for review on master by jiffin tony Thottan (jthottan)

Comment 4 Worker Ant 2017-06-09 09:28:23 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#4) for review on master by jiffin tony Thottan (jthottan)

Comment 5 Worker Ant 2017-06-16 09:15:27 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#5) for review on master by jiffin tony Thottan (jthottan)

Comment 6 Worker Ant 2017-06-21 09:03:43 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#6) for review on master by jiffin tony Thottan (jthottan)

Comment 7 Worker Ant 2017-06-21 09:20:27 UTC

REVIEW: https://review.gluster.org/17331 (dht/hardlink : Remove stale linkto file incase of failure) posted (#7) for review on master by jiffin tony Thottan (jthottan)

Comment 8 Worker Ant 2017-06-22 06:27:46 UTC

COMMIT: https://review.gluster.org/17331 committed in master by Raghavendra G (rgowdapp) 
------
commit 237648780336d41cd6d820c337b38dd13f4d9e72
Author: Jiffin Tony Thottan <jthottan>
Date:   Thu May 18 11:22:16 2017 +0530

    dht/hardlink : Remove stale linkto file incase of failure
    
    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 because linktofile creation fails with EEXIST
    and follow up lookup on linkto file returns gfid-mismatching(old linkto file) and
    finally fails with ESTALE
    
    Steps to produce :
    (From link/00.t test from posix-testsuite)
    Steps executed in script
     * create a file "abc" using root
     * change the ownership of file to a non root user
     * 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
    
    Also tried to fix other bugs in dht_linkfile_create_cbk() and posix_lookup.
    
    Thanks Susant for the help in debugging the issue and suggestion for this patch.
    
    Change-Id: I7a5a1899d3fd1fdb13578b37f9d52a084492e35d
    BUG: 1452084
    Signed-off-by: Jiffin Tony Thottan <jthottan>
    Reviewed-on: https://review.gluster.org/17331
    Smoke: Gluster Build System <jenkins.org>
    Reviewed-by: N Balachandran <nbalacha>
    CentOS-regression: Gluster Build System <jenkins.org>
    Reviewed-by: Raghavendra G <rgowdapp>

Comment 9 Shyamsundar 2017-09-05 17:30:44 UTC

This bug is getting closed because a release has been made available that should address the reported issue. In case the problem is still not fixed with glusterfs-3.12.0, please open a new bug report.

glusterfs-3.12.0 has been announced on the Gluster mailinglists [1], packages for several distributions should become available in the near future. Keep an eye on the Gluster Users mailinglist [2] and the update infrastructure for your distribution.

[1] http://lists.gluster.org/pipermail/announce/2017-September/000082.html
[2] https://www.gluster.org/pipermail/gluster-users/