[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 [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
