Messages in this thread | | | Subject | Re: Subtle NFS/VFS/GLIBC interaction bug | From | Trond Myklebust <> | Date | 12 Mar 2001 15:45:27 +0100 |
| |
>>>>> " " == Leon Bottou <leonb@research.att.com> writes:
> Note the strange numbers in the d_off fields. These are in > fact cookies used internally by nfs. Under nfs2, these are 32 > bit unsigned number, sign extended to 64 bits.
> The last cookie has not been properly sign extended. The > glibc-2.2.2 source code for readdir uses __NR_getdents64 and > converts the result into 32 bit dirents. But it sees that the > last d_ino cannot fit in an off_t and it simply bails out.
> There is already a problem in the making since nfs3 cookies are > 64 bits long. But things should work with nfs2.
This is why I wish glibc would drop the whole idea of relying on seekdir/telldir existing. The LFS does in fact not specify any equivalent seekdir64/telldir64, and most implementations of *NIX don't support them. Currently, the VFS only allows us to support the minimum implementation which is required to support the 32-bit interface.
> I can fix the problem using the following hack:
I've got a more complete one. See the 'IRIX' patch on
http://www.fys.uio.no/~trondmy/src/2.4.2/linux-2.4.2-dir.dif
That patch also sign-extends 32-bit cookies at the NFS level, so that we can a) convert cookies back so that the server accepts them b) match sign-extended 32-bit cookies in the page cache
> That is acceptable as long as filldir_t does not handle 64bits > offsets anyway.
> But it won't last.
Yes and no. All NFSv3 implementations are supposed to support 32-bit client implementations. All you lose here is the ability to handle multi-Gigabyte directories.
Cheers, Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |