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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
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.<br />
<br />
Switching the clients to use NFSv2 solves the problem, but it is not a workable solution since we loose access to files > 4GB.<br />
<br />
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.<br />
<br />
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.
↧