From owner-freebsd-current Sun Aug 29 13:13:29 1999 Delivered-To: freebsd-current@freebsd.org Received: from apollo.backplane.com (apollo.backplane.com [209.157.86.2]) by hub.freebsd.org (Postfix) with ESMTP id 7155F14BF2 for ; Sun, 29 Aug 1999 13:13:26 -0700 (PDT) (envelope-from dillon@apollo.backplane.com) Received: (from dillon@localhost) by apollo.backplane.com (8.9.3/8.9.1) id NAA06936; Sun, 29 Aug 1999 13:12:31 -0700 (PDT) (envelope-from dillon) Date: Sun, 29 Aug 1999 13:12:31 -0700 (PDT) From: Matthew Dillon Message-Id: <199908292012.NAA06936@apollo.backplane.com> To: Dmitrij Tejblum Cc: Doug Rabson , Dmitrij Tejblum , current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris References: <199908291842.WAA04035@tejblum.pp.ru> Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG :> From rfc1813: :> :> If the :> server detects that the cookie is no longer valid, the :> server will reject the READDIR request with the status, :> NFS3ERR_BAD_COOKIE. : :I propose that our cookies are always valid, just like directory :offsets after getdirentries() syscall (on a local filesystems). It isn't possible to do this and still remain synchronized. If the directory changes on the server, the client has no way of knowing whether a cookie corresponds to the same file if you always return a valid response. This breaks the protocol. A local filesystem getdirientries() call is monotonic, stateful, and cache coherent. An NFS readdir rpc is stateless, not monotonic, and can only approximate cache coherency. * an NFS readdir rpc is stateless and not monotonic. The server cannot tell the difference between a new rpc, a retry, or several different processes on the client scanning the same directory (running at different points in the directory). * An NFS readdir rpc can only approximate cache coherency, but that doesn't mean you can throw cache coherency out the window. It approximates cache coherency through the use of the verifier key. If the verifier key supplied by the client is wrong, the server has to tell it so. Otherwise the client's directory cache will get out of sync. It may be fine to allow a directory cache to get out of sync given a single process on a client talking to the NFS server. It is not fine given multiple processes on a client talking to the NFS server and it is not fine given multiple clients. Furthermore, the NFS readdir rpc has no notion of 'dead' directory entries as far as I can tell. This means that from the point of view of an NFS client, directories are always 'compacted'. Since clients may implement a block cache for directories, the server cannot afford to return a valid response if the verifier mismatches because it will screw up the client's block cache for the directory. This is very different from the way most local directories are scanned - filesystems such as UFS maintain dead directory entries and thus allow a directory data block to be scanned without any locking. We cannot use this trick with NFS. Add on top of that the fact that the NFS directory 'block size' may different then a local filesystem's. NFS must translate padding characteristics between the local filesystem and the NFS client's notion of the directory. Even if we did support the notion of dead directory entries in NFS, trying to translate the padding characteristics at the same time would be fairly difficult to accomplish. :> Our NFS client used to have the same problem (a long time ago) and I put :> code into it to re-read the directory if its cookies are stale. : :(According to a mail recently sent to -hackers, that doesn't work. :In -current, the recovery code has a debugging printf(), so I guess :the code only triggered in very rare cases (see above).) This works on FreeBSD clients as far as I know. That is what I thought that email sent to hackers said... that it works w/ FreeBSD clients but not with certain Sun clients. :Anyway, I don't actually care what is correct NFS client behavior. I am :saying that sending "bad cookie" error is not useful for FreeBSD sever. : :Dima My understanding is that it is part of the protocol spec. We are not going to become incompatible with the spec. -Matt Matthew Dillon To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message