From owner-freebsd-current Thu Aug 26 1:54: 9 1999 Delivered-To: freebsd-current@freebsd.org Received: from herring.nlsystems.com (nlsys.demon.co.uk [158.152.125.33]) by hub.freebsd.org (Postfix) with ESMTP id DB57314F18 for ; Thu, 26 Aug 1999 01:54:04 -0700 (PDT) (envelope-from dfr@nlsystems.com) Received: from salmon.nlsystems.com (salmon.nlsystems.com [10.0.0.3]) by herring.nlsystems.com (8.9.3/8.8.8) with ESMTP id KAA46928; Thu, 26 Aug 1999 10:04:06 +0100 (BST) (envelope-from dfr@nlsystems.com) Date: Thu, 26 Aug 1999 10:04:06 +0100 (BST) From: Doug Rabson To: Dmitrij Tejblum Cc: current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris In-Reply-To: <199908252315.DAA02382@tejblum.pp.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Thu, 26 Aug 1999, Dmitrij Tejblum wrote: > Doug Rabson wrote: > > > > This is probably because our server detects that the directory has been > > modified and rejects the solaris client's directory cookies. > > I think we should not ever reject a client's cookie. Consider a local > program that scan the directoty with the getdirentries() syscall. The > offset in the directory is essentially the cookie that would be sent to > an NFS client. But we never "reject" the offset, and everyone is happy. > (Not to mention NFSv2, where we never reject a client's cookie too). > So, what we are trying to achieve by rejecting a NFSv3 client's cookie? Notify the client that the directory contents may have been compacted and therefore that their seek offsets are now wrong. > > > Instead of > > recovering, the solaris client barfs. Its a solaris bug really > > IMHO, it is very arguable. Why the client should "recover" after "stale > cookie" error, but should not recover after "stale filehandle" error? > How should it perform the recovery: If a reliable recovery is possible, > why it is not done on the server? Stale cookie is completely different from stale filehandle and in general it isn't possible to recover on the server. > > (After all, Sun know how NFSv3 should work, since they wrote the spec, > right? :-|) From rfc1813: In the NFS version 3 protocol, each READDIR request includes both a cookie and a cookie verifier. For the first call, both are set to 0. The response includes a new cookie verifier, with a cookie per entry. For subsequent READDIRs, the client must present both the cookie and the corresponding cookie verifier. If the server detects that the cookie is no longer valid, the server will reject the READDIR request with the status, NFS3ERR_BAD_COOKIE. The client should be careful to avoid holding directory entry cookies across operations that modify the directory contents, such as REMOVE and CREATE. It seems to me that the solaris client is holding directory cookies across a REMOVE operation and therefore should expect to get stale cookie errors occaisionally. 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. -- Doug Rabson Mail: dfr@nlsystems.com Nonlinear Systems Ltd. Phone: +44 181 442 9037 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message