Description of problem: As mentioned in the https://bugzilla.redhat.com/show_bug.cgi?id=1358096#c55 , >>>> In case of any lookup sent on a file, if the file already exists but with a different gfid, clients should revalidate/re-issue the lookup to correct the gfid. nfs_lookup() fop starts with setting lookuptype to GF_NFS3_REVALIDATE. But as per the code changes done in the patch mentioned in the comment#52, before doing STACK_WIND on the child xlator lookup, in case if we find cached inode for that file/entry name in the inode table but with inode_ctx not set, we reset lookuptype to GF_NFS3_FRESH. This may have led to nfs xlator not sending fresh lookup on receiving ESTALE. <<< This bug is to track the fix for the above mentioned issue. Version-Release number of selected component (if applicable): 3.1.2 How reproducible: From code-inspection Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Patch posted upstream for review - http://review.gluster.org/15580
upstream master patch : http://review.gluster.org/15580 upstream 3.9 patch : http://review.gluster.org/#/c/15839/ upstream 3.8 patch : http://review.gluster.org/#/c/15840/ downstream patch : https://code.engineering.redhat.com/gerrit/90281
Please note upstream 3.9 & 3.8 patches are yet to be merged as for both of them the merge windows are not yet open.
Tried following test as per discussion with Soumya: Mount with nfs on two clients c1 : create dir/f1 Restart gnfs on server ls dir From c2: rm dir/f1 touch dir/f1 From c1 ls dir/f1 There are no issues seen while listing the file which is recreated with the same name after removal from another client. Marking the BZ verified.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2017-0486.html