This seems to be a bug in the nameless lookup resolution of the Gluster/NFS server code-path (typically happens post restart). NFS xlator seems to be bailing out post LOOKUP of parent directory FH (without resolving the child file entry) resulting in sending stat of parent dir. NFS-client on receiving the attributes of an entry same as it parent, threw an error "Too many levels of symbolic links" to the application.
REVIEW: http://review.gluster.org/14911 (nfs: Reset cs->resolvedhard while resolving an entry) posted (#1) for review on master by soumya k (skoduri)
REVIEW: http://review.gluster.org/14911 (nfs: Reset cs->resolvedhard while resolving an entry) posted (#2) for review on master by soumya k (skoduri)
https://bugzilla.redhat.com/show_bug.cgi?id=1347903 Is this the same problem？
(In reply to jiademing.dd from comment #4) > https://bugzilla.redhat.com/show_bug.cgi?id=1347903 Is this the same > problem？ Yes. It does seem similar. You could confirm from the pkt trace if there is any invalid lookup response to the client (parent directory attributes are copied as a response to the file lookup) post restart of the server.
(In reply to Soumya Koduri from comment #5) > (In reply to jiademing.dd from comment #4) > > https://bugzilla.redhat.com/show_bug.cgi?id=1347903 Is this the same > > problem？ > > Yes. It does seem similar. You could confirm from the pkt trace if there is > any invalid lookup response to the client (parent directory attributes are > copied as a response to the file lookup) post restart of the server. I reported this bug and appended the analysis of the problem in https://bugzilla.redhat.com/show_bug.cgi?id=1347903, but no one reply.
(In reply to jiademing.dd from comment #6) > (In reply to Soumya Koduri from comment #5) > > (In reply to jiademing.dd from comment #4) > > > https://bugzilla.redhat.com/show_bug.cgi?id=1347903 Is this the same > > > problem？ > > > > Yes. It does seem similar. You could confirm from the pkt trace if there is > > any invalid lookup response to the client (parent directory attributes are > > copied as a response to the file lookup) post restart of the server. > > I reported this bug and appended the analysis of the problem in > https://bugzilla.redhat.com/show_bug.cgi?id=1347903, but no one reply. Sometimes few bug updates may get missed because of the heavy inflow of bugs. Please put a need_info on the ones looking at it or the maintainer (can get fom sources/MAINTAINERS file) or send a mail to gluster-devel/gluster-users mailing list for quick responses. Thanks!
COMMIT: http://review.gluster.org/14911 committed in master by Niels de Vos (ndevos) ------ commit 3c485cb896837c8e362fd0b094325002ce806ac4 Author: Soumya Koduri <skoduri> Date: Wed Jul 13 16:24:31 2016 +0530 nfs: Reset cs->resolvedhard while resolving an entry If an entry is not found in the inode table, nfs xlator should be resolving it by sending an explicit lookup to the brick process. But currently its broken in case of NFS3_LOOKUP fop where in the server bails out early resulting in sending pargfid attributes to the client. To fix the same reset 'cs->resolvedhard' so that an explicit lookup is done for the entry in the resume_fn "nfs3_lookup_resume()". Change-Id: I999f8bca7ad008526c174d13f69886dc809d9552 Signed-off-by: Soumya Koduri <skoduri> BUG: 1356068 Reviewed-on: http://review.gluster.org/14911 CentOS-regression: Gluster Build System <jenkins.org> NetBSD-regression: NetBSD Build System <jenkins.org> Smoke: Gluster Build System <jenkins.org> Reviewed-by: Niels de Vos <ndevos>
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.9.0, please open a new bug report. glusterfs-3.9.0 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://lists.gluster.org/pipermail/gluster-users/2016-November/029281.html [2] https://www.gluster.org/pipermail/gluster-users/