Bug 1252348 - using fop's dict for resolving causes problems
using fop's dict for resolving causes problems
Status: CLOSED CURRENTRELEASE
Product: GlusterFS
Classification: Community
Component: protocol (Show other bugs)
3.7.3
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Raghavendra Bhat
:
Depends On: 1244100 1244613 1251409 1255669
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-11 04:41 EDT by Raghavendra Bhat
Modified: 2015-12-01 11:45 EST (History)
2 users (show)

See Also:
Fixed In Version: glusterfs-3.7.4
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 1244613
Environment:
Last Closed: 2015-09-09 05:39:23 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Raghavendra Bhat 2015-08-11 04:41:57 EDT
+++ This bug was initially created as a clone of Bug #1244613 +++

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

Description of problem:

protocol/server tries to resolve the inodes (of both parent and the entry dipeneding upon the fop) whenever a fop comes to it, before continuing the fop. If it cannot find the inode in the inode table for a gfid (soft resolve), then a lookup is sent on it (hard resolve) to build the inode into the inode table. For sending the lookup as part of resolve it uses same xdata as that of the fop. This causes problems in the below situation.

Lru limit has reached. Because of that some of the inodes have been purged. If all the inodes for the dentries present in a directory are purged, then there is no one holding the ref on the parent directory's inode. So soon it also gets moved to the lru list from the active list and might get purged as well if no one holds a ref on that (means, no new entries are created in it and old entries present in it are not looked up).

Now if a create operation comes within that directory, protocol/server is not able to find the inode for the parent directory's gfid and sends a lookup on it. Now if some xlator wants to get some extended attributes as part of lookup, then they add their xattr names in the xdata (ex: bit-rot-stub adding version, sign and bad-object keys into the dict. And the xdata used here is same as that of the create fop's xdata). The lookup succeeds and now create happens with extra xattr names added in the xdata and posix as part of create sets those xattrs. Since bad-object key is also present, this leads to the object that is created to be treated as bad object for rest of its life and will not allow any i/o on it.

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


How reproducible:
Easilu if inode-lru-limit is set to 1.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

http://review.gluster.org/11661 has been sent to master and accepted.

--- Additional comment from Anand Avati on 2015-07-17 02:37:49 EDT ---

REVIEW: http://review.gluster.org/11703 (protocol/server: use different dict for resolving) posted (#1) for review on release-3.7 by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-07-20 06:44:15 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#1) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-07-21 07:28:58 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#2) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-07-24 09:44:47 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#3) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-07-27 02:44:59 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#4) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-07-29 03:03:31 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#5) for review on master by Venky Shankar (vshankar@redhat.com)

--- Additional comment from Anand Avati on 2015-07-31 01:32:42 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#6) for review on master by Venky Shankar (vshankar@redhat.com)

--- Additional comment from Anand Avati on 2015-08-03 01:59:56 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#7) for review on master by Venky Shankar (vshankar@redhat.com)

--- Additional comment from Anand Avati on 2015-08-04 05:04:32 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#8) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-08-10 07:48:01 EDT ---

REVIEW: http://review.gluster.org/11718 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#9) for review on master by Raghavendra Bhat (raghavendra@redhat.com)

--- Additional comment from Anand Avati on 2015-08-11 00:22:13 EDT ---

COMMIT: http://review.gluster.org/11718 committed in master by Venky Shankar (vshankar@redhat.com) 
------
commit c0da330c32312edc4233fe6f660ce8e218638fb5
Author: Raghavendra Bhat <raghavendra@redhat.com>
Date:   Mon Jul 20 16:03:40 2015 +0530

    tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created
    
    This test sets the lru limit of the inode table to 1 and checks if inode forgets
    and resolve cause any problem with bit-rot xattrs (especially bad-file xattr).
    
    Change-Id: I1fa25fa2d31dda8d26e8192562e896e5bddd0381
    BUG: 1244613
    Signed-off-by: Raghavendra Bhat <raghavendra@redhat.com>
    Reviewed-on: http://review.gluster.org/11718
    Tested-by: NetBSD Build System <jenkins@build.gluster.org>
    Tested-by: Gluster Build System <jenkins@build.gluster.com>
    Reviewed-by: Venky Shankar <vshankar@redhat.com>
Comment 1 Anand Avati 2015-08-11 04:53:39 EDT
REVIEW: http://review.gluster.org/11881 (tests: set inode-lru-limit to 1 and check if bit-rot xattrs are wrongy created) posted (#1) for review on release-3.7 by Raghavendra Bhat (raghavendra@redhat.com)
Comment 2 Kaushal 2015-09-09 05:39:23 EDT
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.4, please open a new bug report.

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

Note You need to log in before you can comment on or make changes to this bug.