Description of Problem: After upgrading to the latest "update" kernel, directory operations started too fail for certain directories. As far as I can tell, the problem occurs for all directories that contain so many files that the size reported by 'ls -ld <directory>' is greater than 4096. Version-Release number of selected component (if applicable): kernel-2.4.9-13 How Reproducible: Every time Steps to Reproduce: 1. Get & build "readdir" test application attached at http://bugzilla.redhat.com/bugzilla/showattachment.cgi?attach_id=16346 (attachment to Bug 36897) 2. Find an NFS mounted directory where ls -l reports size > 4096 3. readdir <directory> Actual Results: No output Expected Results: Output is: readdir: status "Success", value "." readdir: status "Success", value ".." + one similar line for each file in the directory Additional Information: I could not reproduce the problem after re-mounting with "mount nfsvers=2", or with kernel-2.4.7-10. My test directories are served by SGI IRIX. I'll try to reproduce for a Linux server later.
The problem reproduces nicely if I create a new directory and add at least 218 empty files to it. The following sequence of commands shows a test run. All output is included, except for the 2nd readdir, where it stops after the 1st page of "more" sh-2.05# mkdir -p /tst sh-2.05# mount fileserv:/u /tst sh-2.05# mkdir -p /tst/subdir sh-2.05# i=1 sh-2.05# while [ $i -lt 219 ]; do touch /tst/subdir/$i; i=`expr $i + 1`; done sh-2.05# ./readdir /tst/subdir sh-2.05# umount /tst sh-2.05# mount -o nfsvers=2 fileserv:/u /tst sh-2.05# ./readdir /tst/subdir | more readdir: status "Success", value "." readdir: status "Success", value "1" readdir: status "Success", value "2" readdir: status "Success", value "3" readdir: status "Success", value "4" readdir: status "Success", value "5" readdir: status "Success", value "6" readdir: status "Success", value "7" readdir: status "Success", value "8" readdir: status "Success", value "9" readdir: status "Success", value ".." readdir: status "Success", value "10" readdir: status "Success", value "11" readdir: status "Success", value "12" readdir: status "Success", value "13" readdir: status "Success", value "14" readdir: status "Success", value "15" readdir: status "Success", value "16" readdir: status "Success", value "17" readdir: status "Success", value "18" readdir: status "Success", value "19" readdir: status "Success", value "20" --More--
Just got an error message from cvs (checkout on a directory where I get the that may be related to this: cvs update: error reading current directory: Value too large for defined data type Also, I couldn't reproduce the problem with a server running Red Hat Linux 7.1 (but does that support NFS 3?)
The above note should read: Just got an error message from cvs (checkout on a directory where I get the described behaviour) that...
If I add option "32bitclients" in /etc/exports, then re-export and re-mount, everything works. In other words, it looks like the NFS client doesn't understand 64-bit (NFS V3) directory cookies. Perhaps not very surprising (as Linux is still essentially 32-bit, as far as i understand), except for the fact that some other kernel versions don't appear to have this problem.
FYI, this problem seems to be the one described by the -seekdir patch available from the nfs-utils maintainers... See http://www.fys.uio.no/~trondmy/src/2.4.14/ and look for the linux-2.4.14-seekdir.dif A similar patch for kernel 2.4.9 can be seen at http://www.fys.uio.no/~trondmy/src/2.4.9/
We're seeing this bug in kernel-2.4.9-21smp attached to SGI IRIX 6.5.13m. NFS3 has the problem, looks like NFS2 is ok.
Thanks for the bug report. However, Red Hat no longer maintains this version of the product. Please upgrade to the latest version and open a new bug if the problem persists. The Fedora Legacy project (http://fedoralegacy.org/) maintains some older releases, and if you believe this bug is interesting to them, please report the problem in the bug tracker at: http://bugzilla.fedora.us/