Hi Ben, I remember hitting this problem as I was working on the new-ish readdir code. The problem has to do with the readdir cookies generated by JFS. In a large directory the same cookie might be reused to refer to different files, and this can confuse the client (it entered an infinite loop before Trond came up with the loop detection). I ended up switching to ext4 to finish the project. - Bryan On Sun, Jul 7, 2013 at 9:13 PM, Ben Hutchings <ben@xxxxxxxxxxxxxxx> wrote: > Jonathan McDowell and Karl Schmidt reported that when sharing a JFS > filesystem through NFS and Samba, NFS clients can report 'readdir loop' > and the directories in question then appear to have duplicate entries on > the client system. > > This was seen with Linux 3.2 on the server and client. The JFS > directory code is basically unchanged since then, but NFS has changed > somewhat. > > The original bug reports were: > http://bugs.debian.org/685407#85 > http://bugs.debian.org/714974 > > The log messages are: > [593351.877678] NFS: directory fs/nfsd contains a readdir loop.Please contact your server vendor. The file: .nfs3proc.o.cmda.com has duplicate cookie 73 > [593351.904689] NFS: directory fs/nfsd contains a readdir loop.Please contact your server vendor. The file: .nfs3proc.o.cmda.com has duplicate cookie 73 > [280774.570555] NFS: directory //accounting contains a readdir loop.Please contact your server vendor. The file: .~lock.credit.rtf1.rtf# has duplicate cookie 199 > > Is this likely to be a problem with JFS, the NFS client or server? Can > anyone suggest how to investigate this further? > > Ben. > > -- > Ben Hutchings > It is easier to write an incorrect program than to understand a correct one. -- 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
