On Sun, 2011-05-29 at 18:55 +0200, RÃdiger Meier wrote: > On Sunday 29 May 2011, Trond Myklebust wrote: > > > Sorry, but that patch makes absolutely no sense whatsoever as a fix > > for the problem you describe. > > It wasn't ment to be a real fix. I just tried to find out where the prob > is roughly located. > > > All you are doing is changing the size > > of the readdir cache entry, which is probably causing a READDIR with > > a duplicate cookie to trigger. > > Yup, my patch "repaired" the test directory and let another one fail. > Currently Ive reverted > commit d1bacf9e, NFS: add readdir cache array > (and a lot followups) to let clients work again. > > > When running with the stock 2.6.39 > > client, do you see the "directory contains a readdir loop." message > > in your syslog? > > Yes, didn't noticed that because I've booted 2.6.39 only a few times. > There are a lot like this: > May 25 13:26:09 kubera-114 kernel: [ 1105.419604] NFS: directory > gen/radar contains a readdir loop. Please contact your server vendor. > Offending cookie: 947700512 > > I hope it's not my server vendor's fault :) > Or does this mean the NFS server is bad rather than the client? It's actually a problem with the underlying filesystem: it is generating readdir 'offsets' that are not unique. In other words, if you use telldir() to list out the offsets for each readdir entry on the server, you will see the same value 947700512 above appear at least two times, which means that 'seekdir()' is also broken, for instance. IOW: This isn't something that we can fix on the NFS client. It needs to be fixed on the server. The only thing that has hidden the problem previously is blind luck (which is why your patch appeared to work). Cheers Trond -- Trond Myklebust Linux NFS client maintainer NetApp Trond.Myklebust@xxxxxxxxxx www.netapp.com -- To unsubscribe from this list: send the line "unsubscribe linux-nfs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
