Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 26 Aug 1999 10:04:06 +0100 (BST)
From:      Doug Rabson <dfr@nlsystems.com>
To:        Dmitrij Tejblum <tejblum@arc.hq.cti.ru>
Cc:        current@FreeBSD.ORG
Subject:   Re: NFSv3 on freebsd<-->solaris 
Message-ID:  <Pine.BSF.4.10.9908260958520.349-100000@salmon.nlsystems.com>
In-Reply-To: <199908252315.DAA02382@tejblum.pp.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.10.9908260958520.349-100000>