[lkml]   [2002]   [Nov]   [28]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [Ext2-devel] Re: [NFS] htree+NFS (NFS client bug?)
>>>>> " " == Stephen C Tweedie <> writes:

> We're only using 31-bit hashes right now. Trond, how will
> other NFS clients react if we return an NFS cookie 32-bits
> wide? We could easily use something like 0x80000000 as an
> f_pos to represent EOF in the Linux side of things, but will
> that cookie work if passed over the wire on NFSv2?

For all other NFS clients that I know of, this is perfectly
acceptable. As far as the Linux kernel goes, it is quite OK, but when
you get to userland, glibc-2.2 and above will insist that this is an
illegal value (they like to sign extend 32-bit values). Causes no end
of trouble, since XFS tends to use '0xffffffff' as the EOF cookie.

I have a patch that hacks the values of such cookies so that glibc
will accept them. That hack will never go in to the official kernel,
so it would be nice if ext2/ext3 could avoid the need for it.

> The alternative is to hack in a special case so that (for
> example) we consider a major htree hash of 0x7fffffff to map to
> an f_pos of 0x7ffffffe and just consider that a possible
> collision, so that 0x7fffffff is a unique EOF for the htree
> tree walker.

That would be fine.

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:31    [W:0.034 / U:11.948 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site