https://bugzilla.novell.com/show_bug.cgi?id=678123
https://bugzilla.novell.com/show_bug.cgi?id=678123#c11
--- Comment #11 from Neil Brown 2011-03-16 07:22:59 UTC ---
Looking at Stefan Dirsch's problem....
The directory contains 87 entries.
The NFS client sends READDIRPLUS requests and receives replies containing
31,30, and 26 entries each. This all appears correct. The cookie numbers
are all unique.
These get stored in the page cache which can hold 102 entries per page, so
they all fit in one page.
Then the getdents64 call returns all those 87 entries - confirming that the
data stored in the page cache looks mostly correct.
glibc makes another getdents64 call (to see if there are any more) and NFS
returns the last 37 entries again. And every time another getdents64
call is made, the same 37 entries are returned. It never returns 0 entries,
so glibc never sees 'eof'.
When nfs finishes with a readdir request it stores the current 'cookie' in
a data structure attached to the 'struct file', and on the next request it
gets that cookie and searches through its table in the page cache to find out
where it was up to.
So this seems to imply that either the wrong cookie is being stored at the
end of one readdir, the wrong cookie is being used to search for the next
readdir, or it finds the wrong place when searching for a cookie - or there
are duplicate cookies (which I already know there are not).
I cannot see how any of these can be happening, and I cannot imagine
any source of error that would cause this directory to respond like this
very repeatably, yet would allow most other directories to still
work perfectly.
I'm not sure where to go next with this one... I might have to try to
insert some tracing to see what is really happening..
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.