[Bugs] [Bug 1244100] New: using fop's dict for resolving causes problems

[bugzilla at redhat.com]

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

            Bug ID: 1244100
           Summary: using fop's dict for resolving causes problems
           Product: GlusterFS
           Version: 3.7.2
         Component: protocol
          Assignee: bugs at gluster.org
          Reporter: rabhat at redhat.com
                CC: bugs at gluster.org, gluster-bugs at redhat.com



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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.