Date: Sun, 29 Aug 1999 13:12:31 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: Dmitrij Tejblum <tejblum@arc.hq.cti.ru> Cc: Doug Rabson <dfr@nlsystems.com>, Dmitrij Tejblum <tejblum@arc.hq.cti.ru>, current@FreeBSD.ORG Subject: Re: NFSv3 on freebsd<-->solaris Message-ID: <199908292012.NAA06936@apollo.backplane.com> References: <199908291842.WAA04035@tejblum.pp.ru>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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).
It isn't possible to do this and still remain synchronized. If the
directory changes on the server, the client has no way of knowing
whether a cookie corresponds to the same file if you always return
a valid response. This breaks the protocol.
A local filesystem getdirientries() call is monotonic, stateful, and
cache coherent. An NFS readdir rpc is stateless, not monotonic, and can
only approximate cache coherency.
* an NFS readdir rpc is stateless and not monotonic. The server cannot
tell the difference between a new rpc, a retry, or several different
processes on the client scanning the same directory (running at different
points in the directory).
* An NFS readdir rpc can only approximate cache coherency, but that
doesn't mean you can throw cache coherency out the window. It
approximates cache coherency through the use of the verifier key. If
the verifier key supplied by the client is wrong, the server has to
tell it so. Otherwise the client's directory cache will get out of
sync.
It may be fine to allow a directory cache to get out of sync given a
single process on a client talking to the NFS server. It is not fine
given multiple processes on a client talking to the NFS server and it
is not fine given multiple clients.
Furthermore, the NFS readdir rpc has no notion of 'dead' directory entries
as far as I can tell. This means that from the point of view of an NFS
client, directories are always 'compacted'. Since clients may implement
a block cache for directories, the server cannot afford to return a valid
response if the verifier mismatches because it will screw up the client's
block cache for the directory. This is very different from the way most
local directories are scanned - filesystems such as UFS maintain dead
directory entries and thus allow a directory data block to be scanned
without any locking. We cannot use this trick with NFS.
Add on top of that the fact that the NFS directory 'block size' may
different then a local filesystem's. NFS must translate padding
characteristics between the local filesystem and the NFS client's notion
of the directory. Even if we did support the notion of dead directory
entries in NFS, trying to translate the padding characteristics at the
same time would be fairly difficult to accomplish.
:> 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).)
This works on FreeBSD clients as far as I know. That is what I thought
that email sent to hackers said... that it works w/ FreeBSD clients but
not with certain Sun clients.
: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
My understanding is that it is part of the protocol spec. We are not
going to become incompatible with the spec.
-Matt
Matthew Dillon
<dillon@backplane.com>
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?199908292012.NAA06936>