Date: Thu, 26 Aug 1999 03:15:00 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Doug Rabson <dfr@nlsystems.com> Cc: current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris Message-ID: <199908252315.DAA02382@tejblum.pp.ru> In-Reply-To: Your message of "Wed, 25 Aug 1999 08:52:40 BST." <Pine.BSF.4.10.9908250851080.72739-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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? (After all, Sun know how NFSv3 should work, since they wrote the spec, right? :-|) Dima 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?199908252315.DAA02382>