Bug 1240190

Summary:	do an explicit lookup on the inodes linked in readdirp
Product:	[Community] GlusterFS	Reporter:	Raghavendra Bhat <rabhat>
Component:	libgfapi	Assignee:	bugs <bugs>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Sudhir D <sdharane>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.7.2	CC:	bugs, gluster-bugs, ndevos, sdharane
Target Milestone:	---	Keywords:	Triaged
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	glusterfs-3.7.3	Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:	1236009	Environment:
Last Closed:	2015-07-30 09:50:03 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:	1236009, 1255639
Bug Blocks:

Description Raghavendra Bhat 2015-07-06 07:26:48 UTC

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

Description of problem:

Like fuse, its better to do an explicit lookup on the inodes linked via readdirp. Otherwise, post linkage directly fops will come and below xlators such as AFR, DHT will not be able to do their house keeping activities for the inode, which they would have done in lookup.

So do an explicit lookup on those inodes linked via readdirp, before proceeding with the first fop on those inodes.

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


How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Anand Avati on 2015-07-02 05:16:18 EDT ---

COMMIT: http://review.gluster.org/11236 committed in master by Niels de Vos (ndevos) 
------
commit c1a8ae20bd055227921d199b952582eca4104f67
Author: Raghavendra Bhat <raghavendra>
Date:   Fri Jun 12 15:12:05 2015 +0530

    libgfapi: send explicit lookups on inodes linked in readdirp
    
    If the inode is linked via readdirp, then the consuners of gfapi which are using
    handles (got either in lookup or readdirp) might not send an explicit lookup on
    that object again (ex: NFS, samba, USS). If there is a replicate volume where
    the replicas of the object are not in sync, then readdirp followed by fops might
    lead data being served from the subvolume which is not in sync with latest
    data. And since lookup is needed to trigger self-heal on that object the
    consumers might keep getting wrong data until an explicit lookup is not done.
    
    Fuse handles this situation by sending an explicit lookup by itself (fuse
    xlator) on those inodes which are linked via readdirp, whenever a fop comes on
    that inode.
    
    The same procedure is done in gfapi as well to address this situation.
    
    Thanks to shyam(srangana) for valuable inputs
    
    Change-Id: I64f0591495dddc1dea7f8dc319f2558a7e342871
    BUG: 1236009
    Signed-off-by: Raghavendra Bhat <raghavendra>
    Reviewed-on: http://review.gluster.org/11236
    Tested-by: NetBSD Build System <jenkins.org>
    Reviewed-by: Shyamsundar Ranganathan <srangana>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Niels de Vos <ndevos>

Comment 1 Anand Avati 2015-07-06 07:33:10 UTC

REVIEW: http://review.gluster.org/11545 (libgfapi: send explicit lookups on inodes linked in readdirp) posted (#1) for review on release-3.7 by Raghavendra Bhat (raghavendra)

Comment 2 Anand Avati 2015-07-06 15:14:08 UTC

COMMIT: http://review.gluster.org/11545 committed in release-3.7 by Niels de Vos (ndevos) 
------
commit 69c434432853e2ba1ee53296f05c6a54ab300d02
Author: Raghavendra Bhat <raghavendra>
Date:   Fri Jun 12 15:12:05 2015 +0530

    libgfapi: send explicit lookups on inodes linked in readdirp
    
              Backport of http://review.gluster.org/11236
    
    If the inode is linked via readdirp, then the consuners of gfapi which are using
    handles (got either in lookup or readdirp) might not send an explicit lookup on
    that object again (ex: NFS, samba, USS). If there is a replicate volume where
    the replicas of the object are not in sync, then readdirp followed by fops might
    lead data being served from the subvolume which is not in sync with latest
    data. And since lookup is needed to trigger self-heal on that object the
    consumers might keep getting wrong data until an explicit lookup is not done.
    
    Fuse handles this situation by sending an explicit lookup by itself (fuse
    xlator) on those inodes which are linked via readdirp, whenever a fop comes on
    that inode.
    
    The same procedure is done in gfapi as well to address this situation.
    
    Thanks to shyam(srangana) for valuable inputs
    
    Change-Id: I4230fae8e0b01a95c056282b08ed30832d4804a7
    BUG: 1240190
    Signed-off-by: Raghavendra Bhat <raghavendra>
    Reviewed-on: http://review.gluster.org/11545
    Tested-by: NetBSD Build System <jenkins.org>
    Tested-by: Gluster Build System <jenkins.com>
    Reviewed-by: Shyamsundar Ranganathan <srangana>
    Reviewed-by: Niels de Vos <ndevos>

Comment 3 Kaushal 2015-07-30 09:50:03 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.7.3, please open a new bug report.

glusterfs-3.7.3 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://thread.gmane.org/gmane.comp.file-systems.gluster.devel/12078
[2] http://thread.gmane.org/gmane.comp.file-systems.gluster.user