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>