> The client system -- A FreeBSD
> client system - has a buffer cache. The buffer cache holds an abstraction
> for both files and directories.
Well, the discussion is about FreeBSD NFS server, not about FreeBSD NFS
client. Neither FreeBSD server cannot assume FreeBSD client, nor
FreeBSD client can assume FreeBSD server. The NFS server is a simple
thing that just do what the client requested, for example read the
directory. Bugs in the FreeBSD NFS client is completely different story.
> Our NFS implementation on the client caches the NFS directory via the
> buffer cache. It translates the cookies returned by the server to
> a block number and offset as cached in the client's buffer cache.
> See nfs_readdirrpc() in sys/nfs/nfs_vnops.c
> This creates a directory-block abstraction on the client. The 'cookies'
> the client returns to processes are based on this abstraction and do not
> match the cookies returned by the server.
> The problem that we have is that our buffer cache abstraction essentially
> fits a variable number of directory entries returned from the server. If
> a file is created or deleted on the server, our buffer cache abstraction
> gets thrown for a loop.
The client _cannot_ depend on that if a file is created or removed on the
server, the "bad cookie" error is returned in next readdir. RFC1813 does not
require it in any way.
> In order to maintain consistency within the set of cached pages (note:
> I'm not talking about cache coherency with the server here, just
> consistency within the buffer cache on the client), our buffer cache
> abstraction is currently dependant on the verifier key changing on the
> server. I don't why it was done this way -- perhaps mtime was found to
> not be sufficient. Maybe because it doesn't have sufficient resolution
> under NFSv2. Under NFSv3 it should theoretically have sufficient
> resolution but how many servers do you know keep the nanoseconds field
I don't believe in it. First of all, NFSv2 has no verifiers, and work
reasonably well. (There is a belief that NFSv2 is much more reliable
than NFSv3, you know.) Then, invalidation of cached data is heavily
depended on mtime anyway. The client don't do readdir RPC if it think
that its cache is valid, it only verify the mtime. Finally, -current
has a debugging printf in "bad cookie" handling code for about 4
months, and noone complain that his logs filled with the message.
I think I now understand why the "bad cookie" handling code don't do
the right thing. Removing files in the directory effectively shift its
content to the left. So, if you read the directory and remove files in
the same time, you will miss some entries.
> When applied to files, the use of mtime to determine when to flush the
> cache is nothing more then an inconvenience. But the use of mtime to
> determine when to flush a directory cache can be fatal.
I still don't see why.
> If you want to change the way our directory verifier works, you have to
> completely rewrite the directory caching code for the client. I think
> you can argue that the verifier is not being implemented properly, but
> I'm not going to let anyone change it unless the directory caching code
> on the client is rewritten at the same time to use the server's cookies
> Right now the server's cookies are only used by the client to demark
> client-buffer-cache buffer boundries. The actual cookies returned to
> the *process* running on the client are translated from the client's
> buffer cache abstraction of the NFS directory.
> The change that would have to be made would be for the server's cookies
> to be passed through all the way to the process sitting on the client
> rather then translated in the buffer cache. Then cache consistency in
> our client would then not be as sensitive to the varying amounts of
> information the server sends us and we could safely leave the verifier
> alone on the server. This would require us to change the abstraction our
> client uses significantly -- it would not longer be able to use the
> cookies passed to it by the user process as direct offsets into the
> client's buffer cache.
Hmm. I don't think such a big changes in the directory caching is
necessary at all, though I didn't actually think about it. Anyway, the
verifiers only add to the breakage (see above).
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message