Subject: Re: Directory cookies, the continuing story
To: Frank van der Linden <firstname.lastname@example.org>
From: Robert Black <email@example.com>
Date: 07/31/1997 18:59:00
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.