2017-10-18 05:47 UTC

View Issue Details Jump to Notes ]
IDProjectCategoryView StatusLast Update
0006246CentOS-5kernelpublic2013-09-05 14:39
Platformx86_64OSCentOSOS Version5.9
Product Version5.9 
Target VersionFixed in Version 
Summary0006246: The 32 / 64 bit dir name hash patches for ext3 and ext4 break NFS v3 clients on 32 bit machines
DescriptionWe have a CentOS 5.x x86_64 server which acts as NFS server for a large number of 32 bit NFSv3 clients running old kernels.

This work fine with kernel 2.6.18-308.24.1.el5 from CentOS 5.8. Upgrading to CentOS 5.9 with kernel 2.6.18-348.1.1.el5 breaks readdir on these clients.

The issue is that the ext3/ext4: "return 32/64-bit dir name hash according to usage type" patches introduced in kernel 2.6.18-326.el5 now generate 64 bit cookies in the readdir and readdirplus calls. This causes a problem with 32 bit NFSv3 clients in applications that are not compiled with large file support (LFS). These apps call readdir (and not readdir64), which glibc implements by calling getdents64 and checking that the d_off value fits in 32 bits. As the cookies are now on 64 bits, d_off is often larger than 32 bits and hence the readdir calls fail. Hence applications not compiled with LFS often fail listing directories.

This worked in CentOS 5.8 and before because the dir name hash was always on 32 bits. Now it is on 32 bits only when generated for a 32 bit app or for a NVSv2 client.

Switching the clients to use NFSv2 solves the problem, but it is not a workable solution since we loose access to files > 4GB.

Note that these NFS clients are running a Linux kernel 2.6.10, I think more recent kernels work around this problem by truncating or rehashing the cookies to 32 bits at the client.

Admittedly these clients are very old, but this is a regression compared to CentOS 5.8. A tunable somewhere to disable this 64 bit hashes either per NFS export, per ext3/ext4 mount or globally would solve this regression for those for which it matters.
Steps To ReproduceExport an ext3 or ext4 filesystem via NFS, from a CentOS 5.9 64-bit server.

Mount it from a 32-bit NFS client, suing NFSv3.

Do directory listings at the client on the NFSv3 mount, from an application compiled without LFS support.

The readdir() calls will often fail with EOVERFLOW.
TagsNo tags attached.
Attached Files

related to 0006241resolvedtoracat See: 0005496: readdir() fails to return all entries of a NFS directory 



diego.santacruz (reporter)

Seems that this is exactly what is reported in the forum:



toracat (manager)

Closing as a duplicate of bug #6241.


toracat (manager)



toracat (manager)

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


diego.santacruz (reporter)

Finally got the time to reboot the server with the new kernel to test.

Tested with kernel 2.6.18-348.12.1.el5 and same client as before and the issue is not resolved. The same problem is still present.

-Issue History
Date Modified Username Field Change
2013-02-08 23:27 diego.santacruz New Issue
2013-02-08 23:38 diego.santacruz Note Added: 0016466
2013-02-08 23:45 tru Relationship added duplicate of 0006241
2013-02-09 18:30 toracat Note Added: 0016471
2013-02-09 18:30 toracat Status new => closed
2013-02-09 18:30 toracat Resolution open => duplicate
2013-02-09 22:07 toracat Note Added: 0016475
2013-02-09 22:07 toracat Status closed => feedback
2013-02-09 22:07 toracat Resolution duplicate => reopened
2013-02-09 22:07 toracat Status feedback => new
2013-02-09 22:07 toracat Relationship deleted 0006241
2013-02-09 22:08 toracat Relationship added related to 0005496
2013-02-09 22:10 toracat Relationship added related to 0006241
2013-02-09 22:13 toracat Relationship deleted related to 0005496
2013-04-17 12:21 toracat Note Added: 0017225
2013-04-17 12:21 toracat Status new => feedback
2013-09-05 14:39 diego.santacruz Note Added: 0017935
2013-09-05 14:39 diego.santacruz Status feedback => assigned
+Issue History