Date: Tue, 11 Mar 1997 16:35:17 -0700 (MST) From: Terry Lambert <terry@lambert.org> To: joerg_wunsch@uriah.heep.sax.de Cc: hackers@freebsd.org, dfr@freebsd.org Subject: Re: NFSv3 (was: Maybe a showstopper...) Message-ID: <199703112335.QAA26347@phaeton.artisoft.com> In-Reply-To: <19970311225100.SW24783@uriah.heep.sax.de> from "J Wunsch" at Mar 11, 97 10:51:00 pm
next in thread | previous in thread | raw e-mail | index | archive | help
> Who had thought that Sun doesn't implement the NFSv3 specification > correctly? :-)) If i read the specs correctly, the above behaviour is > allowed, and the client should be able to handle this. (Note that > it's possible that the FreeBSD server implementation is overly > restrictive however. See below for a discussion.) [ ... ] > ``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, together with a cookie > per entry. For subsequent READDIRs, the client must present both the > cookie and the corresponding cookie verifier. Directory entry cookies > may become invalid if the directory is modified. If the server detects > that the cookie is no longer valid, it will reject the 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.'' Our server is *incorrectly* determining the cookie to be invalid; the only operations which may invalidate a cookie are operations where directory entries have been created in the directory block in which the cookie exists, or deletion of the entire block which contains the cookie (which will occur if the block containing the cookie was the last block in a set of blocks and became empty, so as to cause the cookie block to be truncated. This is new BSD4.4 specific behaviour). Everything else will not modify the directory layout itself. A cookie may be validated in a directory block in all other cases by traversing the block from the start looking for valid entries; if it is the first entry, you look for a non-zero inode. If it is the second or subsequent entry, you look for a valid entry ending just before the entry in question (guaranteeing that the entry for which the cookie is valid has not been coelesced into a previous entry). If the cookie entry has been coelesced (because the entry it refereed to has been deleted), then the cookie is still valid, providing there were no create operations in the block: you can simply advance the pointer to the next valid entry, normally, since you are guaranteed that the cookie itself pointed to a coelesced entry and was invalid because of coelesce. This depends on the fact that a create operation did not cause a coelesce collapse for space recovery to create the new directory entry. All that said, it is invalid for Sun to not accept the error code NFS2ERR_BAD_COOKIE invalidation of the cookie, even if it were improper for FreeBSD to invalidate the cookie. Sun is not permitted to assume implementation. There are plenty of FS's for which the above sequence of events is not true. > Maybe somebody with a SunOS support contract should open a trouble > ticket for this. ;-) Yes. > ``One implementation of the cookie verifier mechanism might be for the > server to use the modification time of the directory. This might be > overly restrictive, however. A better approach would be to record the > time of the last directory modification that changed the directory > organization in a way which would make it impossible to reliably > interpret a cookie.'' Yes. To do this fully, you would have to change it on create (and on truncate, in the BSD4.4 case) operations which affected the block for which the cookie reference was targeted: the validators would have to be on a block-by-block basis rather than on a directory basis to only *EVER* invalidate a cookie based on a directory change. In any case, it's still bogus for Sun to depend on this. Good catch, BTW. Regards, Terry Lambert terry@lambert.org --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199703112335.QAA26347>