On Jul 30,  3:52pm, Frank van der Linden wrote:
> Subject: Directory cookies, the continuing story
>
> I've changed the NFS readdir code to fix the 'ghost entry' problem. See
> my message to this list on April 9th, titled "NFSv3 cookie jar" for
> more detail.(*)
>
> In short it comes down to doing what the v2 code (pre-lite2) did, with
> as additions to make it work:
>
> 	1) a per-NFS node hashtable to do 64bit cookie -> 32bit blocknumber
> 	   translation for the sake of the buffer cache.
> 	2) Widen the path through the kernel to be able to handle
> 	   64bit cookies. Which comes down to making the cookies
> 	   returned by VOP_READDIR off_t, not u_long.
> 	3) Make the directory(3) routines read in all (most) of
> 	   an NFS directory in one go, to avoid troubles
> 	   with changed directories and BAD_COOKIE errors from
> 	   the server. Although most servers will probably
> 	   never return those. See the message mentioned above
> 	   for details.
>
> There are issues wrt emulations that can only handle 32bit cookies.
> They are unlikely to become a problem in practice, as I don't know
> of any NFS server that returns cookies that have data in the upper 32 bits.
> This is hard to work around, especially if you consider that binaries
> running under emulation can read directories in unexpectedly sized
> chunks. Like one entry at a time with (old Linux binaries). It can probably
> be done right if a completely seperate NFS directory block cache is kept,
> not using the normal buffer cache. With an additional lookup mechanism
> in which you can find _any_ entry using an opaque key (a cookie), because
> you can't count on the directory being read in the chunk amount that
> you would like. This can be quite a bit of overhead both in time and
> space for large directories (1000s of files), so I have decided not to
> do this, not for now at least.

I believe IRIX 6.2 and later returns cookies with data in the upper 32 bits.

Cheers

Rob Black