Created attachment 853252 [details]
volx log globbed copy

Description of problem:

When quota is enabled globbed file actions, e.g. cp foo* destdir, the logs are flooded with error messages:
  ... (-->/usr/lib64/glusterfs/3.4git/xlator/features/marker.so(mq_dict_set_contribution+0x156) [0x7ffddccf8b76]) 0-marker: invalid argument: loc->parent

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

3.4.2 and earlier


How reproducible:

Create a volume, enable quota, set limit-usage. mount the volume at, e.g. /mnt. Copy a few files to /mnt, make a few subdirs on /mnt, then `cd /mnt; cp $single-file-name $subdirX`. Note that there are no errors in the volume log file.

Now do `cp $wildcard* $subdirY` and notice the error entries in the log file.

Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

See the attached log files. (N.B. they have lots of extra logging that's not in the git source.)  The files here are have names dummy[123456789] and subdirs are dir[123456789]. There's a race condition in the resolve code. At line 261 of the var-tmp-volx.log.glob you can see that when trying to resolve inode d6273087-0639-46df-9f3d-5a9070977c0f it's not found in the inode table, and then is inserted at line 264 in the call to inode_link().

Looking at var-tmp-volx.log.noglob it's apparent that the inode is inserted into the inode table earlier (earlier than the glob case), and the respective lookup succeeds.

It appears that in the glob case, the reason the inode isn't inserted in the inode table sooner is because these lines are commented out in the readdir and readdirp fops in server-rpc-fops.c, in server_readdirp_cbk() and server_readdir_cbk():
  
        /* TODO: need more clear thoughts before calling this function. */
        /* gf_link_inodes_from_dirent (this, state->fd->inode, entries); */

Which is not to say that these lines should be blindly uncommented. Maybe instead we need to simply not log an error when loc->parent == NULL in mq_dict_set_contribution()?