Date: Sun, 29 Aug 1999 22:42:01 +0400 From: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> To: Doug Rabson <dfr@nlsystems.com> Cc: Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris Message-ID: <199908291842.WAA04035@tejblum.pp.ru> In-Reply-To: Your message of "Thu, 26 Aug 1999 10:04:06 BST." <Pine.BSF.4.10.9908260958520.349-100000@salmon.nlsystems.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[sorry for some delay...] Doug Rabson wrote: > > 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. You apparently missed my above paragraph. Do we notify a local process about such a condition? Then, what is so special about compacting? What if I quickly moved out a directory content and replaced it with something completely different? How you can recover after it? With rm -r, the recovery is easy, but how the recovery will work if the program is, say, du? > 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). > 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. Yes. FreeBSD programs typically use fts(3), which read whole directory before return its content to the application. That is, the rule is honored. But this solution is in the userland. > 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).) 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 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?199908291842.WAA04035>