Bug 1413057

Summary:	[ganesha+ec]: Contents of original file are not seen when hardlink is created
Product:	[Community] GlusterFS	Reporter:	Pranith Kumar K <pkarampu>
Component:	disperse	Assignee:	bugs <bugs>
Status:	CLOSED EOL	QA Contact:
Severity:	urgent	Docs Contact:
Priority:	unspecified
Version:	3.9	CC:	aloganat, amukherj, aspandey, bugs, dang, ffilz, jthottan, mbenjamin, nchilaka, pgurusid, pkarampu, rcyriac, rhinduja, rhs-bugs, skoduri, storage-qa-internal
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1409730	Environment:
Last Closed:	2017-03-08 12:33:55 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:
Bug Depends On:	1409730
Bug Blocks:	1408836, 1412916

Comment 1 Pranith Kumar K 2017-01-13 14:04:49 UTC

Steps to Reproduce:
1. Create ganesha cluster and create 2*(4+2) EC volume.
2. Enable nfs-ganesha on the volume with mdcache settings.
3. Mount the volume.
4. Create a file and write contents to it.
5. Create hard link to that file.
6. Read the contents of the file.

Actual results:
Contents of original file are not seen when hardlink is created

Expected results:
Contents should not get removed

Additional info:

[root@dhcp47-49 ec_test]# echo "testfile" > test1
[root@dhcp47-49 ec_test]# cat test1
testfile
[root@dhcp47-49 ec_test]# ls -lhrtia test1
10548474259765385418 -rw-r--r--. 1 root root 9 Dec 27 20:38 test1
[root@dhcp47-49 ec_test]# ln test1 test1_hlink
[root@dhcp47-49 ec_test]# ls -lhrtia test1 test1_hlink
10548474259765385418 -rw-r--r--. 2 root root 0 Dec 27 20:38 test1_hlink
10548474259765385418 -rw-r--r--. 2 root root 0 Dec 27 20:38 test1
[root@dhcp47-49 ec_test]# cat test1
[root@dhcp47-49 ec_test]# cat test1_hlink
[root@dhcp47-49 ec_test]# 
[root@dhcp47-49 ec_test]# 
[root@dhcp47-49 ec_test]# cat test1
[root@dhcp47-49 ec_test]# cat test1_hlink
[root@dhcp47-49 ec_test]# cat test1
[root@dhcp47-49 ec_test]# cat test1

Comment 2 Worker Ant 2017-01-13 14:41:19 UTC

REVIEW: http://review.gluster.org/16411 (cluster/ec: Do lookup on an existing file in link) posted (#1) for review on release-3.9 by Pranith Kumar Karampuri (pkarampu)

Comment 3 Worker Ant 2017-01-18 09:07:04 UTC

REVIEW: http://review.gluster.org/16411 (cluster/ec: Do lookup on an existing file in link) posted (#2) for review on release-3.9 by Pranith Kumar Karampuri (pkarampu)

Comment 4 Worker Ant 2017-01-18 09:48:56 UTC

COMMIT: http://review.gluster.org/16411 committed in release-3.9 by Pranith Kumar Karampuri (pkarampu) 
------
commit 6e46104c299f61c180674a455f83b6bcec032aef
Author: Pranith Kumar K <pkarampu>
Date:   Wed Jan 4 13:37:23 2017 +0530

    cluster/ec: Do lookup on an existing file in link
    
    Problem:
    In link fop lookup is happening on the new link which doesn't exist so the iatt
    ec serves parent xlators has size as zero which leads to 'cat' giving empty output
    
    Fix:
    Change code so that lookup happens on the existing link instead.
    
     >BUG: 1409730
     >Change-Id: I70eb02fe0633e61d1d110575589cc2dbe5235d76
     >Signed-off-by: Pranith Kumar K <pkarampu>
     >Reviewed-on: http://review.gluster.org/16320
     >Smoke: Gluster Build System <jenkins.org>
     >Reviewed-by: Xavier Hernandez <xhernandez>
     >Tested-by: Xavier Hernandez <xhernandez>
     >CentOS-regression: Gluster Build System <jenkins.org>
     >NetBSD-regression: NetBSD Build System <jenkins.org>
    
    BUG: 1413057
    Change-Id: Ia48f615fd41f0fa7f3ffe8eb613d90a05eb68c32
    Signed-off-by: Pranith Kumar K <pkarampu>
    Reviewed-on: http://review.gluster.org/16411
    NetBSD-regression: NetBSD Build System <jenkins.org>
    CentOS-regression: Gluster Build System <jenkins.org>
    Smoke: Gluster Build System <jenkins.org>
    Reviewed-by: Xavier Hernandez <xhernandez>

Comment 5 Kaushal 2017-03-08 12:33:55 UTC

This bug is getting closed because GlusterFS-3.9 has reached its end-of-life [1].

Note: This bug is being closed using a script. No verification has been performed to check if it still exists on newer releases of GlusterFS.
If this bug still exists in newer GlusterFS releases, please open a new bug against the newer release.

[1]: https://www.gluster.org/community/release-schedule/