|View Issue Details|
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0006246||CentOS-5||kernel||public||2013-02-08 23:27||2013-09-05 14:39|
|Target Version||Fixed in Version|
|Summary||0006246: The 32 / 64 bit dir name hash patches for ext3 and ext4 break NFS v3 clients on 32 bit machines|
|Description||We 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 Reproduce||Export 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.
|Tags||No tags attached.|
Seems that this is exactly what is reported in the forum:
|Closing as a duplicate of bug #6241.|
|kernel-2.6.18-348.4.1.el5 has been released. Does the problem still exist in this version?|
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.
|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|