Feng Shuo <steve.shuo.feng@xxxxxxxxx> wrote: > Use the same adaptive readdirplus mechanism as NFS: > > http://permalink.gmane.org/gmane.linux.nfs/49299 > > If the user space implementation wants to disable readdirplus > temporarily, it could just return ENOTSUPP. Then kernel will > recall it with readdir. The version of this patch in "for-next" in git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse.git (commit 4582a4ab2a0e7218449fb2e895d0aae9ea753c94) seems to be causing problems for me with "find -ls" (I trivially backported all the for-next patches to 3.7.5) I see getdents() returning a single d_name="" entry at the end of the list, leading to infinite looping when combined with the userspace patches I posted in http://mid.gmane.org/20130202043316.GA19751@xxxxxxxxxxxxx Normally getdents() returns 0 to indicate EOF on the directory; but with this patch, I no longer get that... This only seems to happen on large directories which require multiple getdents() calls. Sometimes "ls -l" will succeed and "find -ls" will fail, and sometimes strace seems to make the problem go away... It could be a bug in my end in userspace, too. However, reverting the version of this patch that landed in for-next seems to avoid the issue for me. I've also verified none of my userspace code is sending dentries with an empty name. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
