View Issue Details

IDProjectCategoryView StatusLast Update
0006241CentOS-5kernelpublic2013-09-18 16:49
Reporterblixco Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status resolvedResolutionfixed 
Platformi386OSCentOSOS Version5
Product Version5.9 
Summary0006241: See: 0005496: readdir() fails to return all entries of a NFS directory
DescriptionWe're seeing the same behavior reported (and reportedly fixed) in 0005496: readdir() fails to return all entries of a NFS directory
Steps To ReproduceMount a directory via NFS (multiple options tried, currently include nodirplus, rsize=32768,wsize=32768,timeo=600,actimeo=120,intr,tcp,nfsvers=3

ls and cp commands fail with more than 100 items in the NFS directory (ls won't show the complete number of items, cp won't copy more that 100).
Additional InformationAppears to be readdir() that fails. System is running 2.6.32-279.19.1.el6.x86_64 as a VM host in a VirtualBox system, server that is exporting is an RHEL5.9 box; non RHEL/CentOS 6.x clients don't see the issue.
TagsNo tags attached.

Relationships

related to 0005496 resolvedIssue Tracker CentOS-6 readdir() fails to return all entries of a NFS directory 
related to 0006246 assignedkbsingh@karan.org CentOS-5 The 32 / 64 bit dir name hash patches for ext3 and ext4 break NFS v3 clients on 32 bit machines 
related to 0006213 assignedkbsingh@karan.org CentOS-5 NFS mounts don't show all directory entries 

Activities

toracat

toracat

2013-02-06 08:45

manager   ~0016440

I believe I am seeing a similar NFS issue with the server EL 5.9 and the client EL 6.3. Directory listing has duplicate files and/or missing files. There seems to be no problem if the client is EL 5.x. Under investigation.
toracat

toracat

2013-02-06 08:51

manager   ~0016441

Possibly related:

https://bugzilla.redhat.com/show_bug.cgi?id=736394#c13
toracat

toracat

2013-02-06 09:38

manager   ~0016442

See also this forum thread "5.9 NFSv3 bug?" :

https://www.centos.org/modules/newbb/viewtopic.php?topic_id=41070&forum=37
blixco

blixco

2013-02-06 15:15

reporter   ~0016443

Our 5.9 box is running 2.6.18-348.el5PAE, 32bit. An update is available for 2.6.18-348.1.1.el5; should we try that? The server is part of our source repo, so there will be some lead time needed to schedule the downtime.
toracat

toracat

2013-02-06 19:26

manager   ~0016444

I would recommend keeping the system up to date whenever you can. Also, that is the only way you can find out if the latest kernel resolves the issue. In _my_ case, the problem persisted with 2.6.18-348.1.1.el5.
toracat

toracat

2013-02-08 16:12

manager   ~0016463

Apparently this is a known issue:

https://access.redhat.com/knowledge/solutions/306063
blixco

blixco

2013-02-08 16:16

reporter   ~0016464

Ack. So no fix for 5.9 kernels.

That's painful, but it's also an RHEL5.9 issue and not a CentOS 6.3 issue, so this bug can be disposed of accordingly.
toracat

toracat

2013-02-08 16:50

manager   ~0016465

Moved to c5.9, 32-bit. Let's keep this open so that we can update this if/when there is progress upstream.
toracat

toracat

2013-02-09 18:31

manager   ~0016472

Bug #6246 was closed as a duplicate of this bug.
diego.santacruz

diego.santacruz

2013-02-09 21:23

reporter   ~0016474

I doubt that bug 0006246 is a duplicate of this one. In bug 0006246 the server is 5.9 64-bit and the bug (as far as reading the patch goes) cannot happen on a 32 bit machine (x86) as in that case the direntry hashes are on 32 bits.

This bug is marked for 5.9 32-bit, whereas bug 0006246 is 5.9 64-bit only.

Maybe the root cause is the same, but the symptoms should be different.
toracat

toracat

2013-02-09 22:09

manager   ~0016476

bug #6246 reopened and changed the relationship to "related to".
toracat

toracat

2013-04-17 12:19

manager   ~0017223

kernel-2.6.18-348.4.1.el5 has been released. Does the problem still exist in this version?
blixco

blixco

2013-04-17 21:00

reporter   ~0017228

I'll check. That particular group of users may have moved back to rhel on client and server sides, so it may take me a bit to test.
toracat

toracat

2013-09-18 16:25

manager   ~0018018

@blixco

Any result on this?
blixco

blixco

2013-09-18 16:32

reporter   ~0018019

I was only able to test very briefly, and *did not see* the same issue, but my testing wasn't very thorough. The original environment that produced the issue was migrated off to rhel clients and servers.
toracat

toracat

2013-09-18 16:39

manager   ~0018020

Thanks for the reply. I'm going to close this ticket as 'resolved'. Feel free to reopen if you find something to note.

Issue History

Date Modified Username Field Change
2013-02-05 17:52 blixco New Issue
2013-02-05 18:22 tru Relationship added related to 0005496
2013-02-06 08:45 toracat Note Added: 0016440
2013-02-06 08:51 toracat Note Added: 0016441
2013-02-06 09:38 toracat Note Added: 0016442
2013-02-06 15:15 blixco Note Added: 0016443
2013-02-06 19:26 toracat Note Added: 0016444
2013-02-07 16:12 toracat Status new => confirmed
2013-02-08 16:12 toracat Note Added: 0016463
2013-02-08 16:16 blixco Note Added: 0016464
2013-02-08 16:48 toracat Project CentOS-6 => CentOS-5
2013-02-08 16:50 toracat Note Added: 0016465
2013-02-08 16:50 toracat Platform x86_64 => i386
2013-02-08 16:50 toracat Product Version 6.3 => 5.9
2013-02-08 18:55 toracat OS Version 6 => 5
2013-02-08 23:45 tru Relationship added has duplicate 0006246
2013-02-09 18:31 toracat Note Added: 0016472
2013-02-09 21:23 diego.santacruz Note Added: 0016474
2013-02-09 22:08 toracat Relationship deleted has duplicate 0006246
2013-02-09 22:09 toracat Note Added: 0016476
2013-02-09 22:10 toracat Relationship added related to 0006246
2013-02-11 19:32 toracat Relationship added related to 0006213
2013-04-17 12:19 toracat Note Added: 0017223
2013-04-17 12:19 toracat Status confirmed => feedback
2013-04-17 21:00 blixco Note Added: 0017228
2013-04-17 21:00 blixco Status feedback => assigned
2013-09-18 16:25 toracat Note Added: 0018018
2013-09-18 16:25 toracat Status assigned => feedback
2013-09-18 16:32 blixco Note Added: 0018019
2013-09-18 16:32 blixco Status feedback => assigned
2013-09-18 16:39 toracat Note Added: 0018020
2013-09-18 16:39 toracat Status assigned => resolved
2013-09-18 16:39 toracat Resolution open => fixed