Bug 55864
Summary: | (NFS IRIX)readdir() fails for large NFS directories | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Toralf <bugzilla> |
Component: | kernel | Assignee: | Steve Dickson <steved> |
Status: | CLOSED CURRENTRELEASE | QA Contact: | Brock Organ <borgan> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.2 | CC: | alexj, robert.jones, tony.chandler |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2004-09-30 15:39:15 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Toralf
2001-11-07 21:51:38 UTC
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/ |