Bug 905933
Summary: | GlusterFS 3.3.1: NFS Too many levels of symbolic links/duplicate cookie | ||
---|---|---|---|
Product: | [Community] GlusterFS | Reporter: | Justin Albstmeijer <justin> |
Component: | nfs | Assignee: | GlusterFS Bugs list <gluster-bugs> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | |
Severity: | urgent | Docs Contact: | |
Priority: | unspecified | ||
Version: | mainline | CC: | bugs, davdunc, gluster-bugs, justin, ndevos, rjoseph, toracat, vagarwal |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | x86_64 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2014-10-20 14:07:42 UTC | Type: | Bug |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Justin Albstmeijer
2013-01-30 14:01:48 UTC
We swithed to detachting and attaching a dedicated NFS network interface (Eni) on failover to the other server instead of only detachting and attaching the ip number. This way of failover does not show this problem. If anyone is still interested in debugging the issue and wants me to test a version of GlusterFS that includes a patch potentially fixing the initial problem, I'm willing to test this. We had investigated this and did not find this to be an issue: Tested the issue in kernel-2.6.32-358.el6.x86_64 and the issue is not seen here. The "Too many levels of symbolic links" error is most likely due to bug in NFS client. Can you please check if you face the issue with the latest kernel? This could indeed be an issue with the NFS-client (provide by the Linux kernel). Could you let us know if you can still reproduce this problem on more recent kernel versions? If you can reproduce this, can you let us know the exact steps how to do so? One of the most important things would be the number of files in the directory. capturing a tcpdump on the NFS-client (with "-s 0") and matching logs should help in analysing this behaviour too. I have no test setup anymore to reproduce these tests. For me the problem was solved by using a different way of moving the ip between the NFS servers like described on 2013-09-12 04:54:19 Okay, thanks. I'll close this out for now. If this issue happens to return again, please open a new bug. |