Date: Mon, 30 Aug 1999 17:40:56 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Matthew Dillon <dillon@apollo.backplane.com> Cc: Doug Rabson <dfr@nlsystems.com>, current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris Message-ID: <199908301340.RAA78840@arc.hq.cti.ru> In-Reply-To: Your message of "Sun, 29 Aug 1999 16:44:33 PDT." <199908292344.QAA07737@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> 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 > updated? 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 > directly. Really? > 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). Dima To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199908301340.RAA78840>