Date: 12 Mar 1997 12:01:45 +0000 From: Doug Rabson <dfr@render.com> To: joerg_wunsch@uriah.heep.sax.de (Joerg Wunsch) Cc: hackers@FreeBSD.ORG Subject: Re: NFSv3 (was: Maybe a showstopper...) Message-ID: <sek9nd71zp.fsf@minnow.render.com> In-Reply-To: j@uriah.heep.sax.de's message of Tue, 11 Mar 1997 22:51:00 %2B0100 References: <Pine.NEB.3.95.970310211652.24717A-100000@mail.cdsnet.net> <Pine.BSF.3.95q.970311110509.23141G-100000@fallout.campusview.indiana.edu> <19970311194645.GS08931@uriah.heep.sax.de> <19970311225100.SW24783@uriah.heep.sax.de>
next in thread | previous in thread | raw e-mail | index | archive | help
j@uriah.heep.sax.de (J Wunsch) writes: > > As J Wunsch wrote: > > > sunny.9dca8c93 > freeboy.nfs: 124 readdirplus fh 4,12/1 1048 bytes @ 0 (DF) > > freeboy.nfs > sunny.9dca8c93: reply ok 592 readdirplus > > sunny.9dca8c94 > freeboy.nfs: 112 remove fh 4,12/1 ld.exp (DF) > > freeboy.nfs > sunny.9dca8c94: reply ok 144 remove > > sunny.9dca8c95 > freeboy.nfs: 120 readdir fh 4,12/1 1048 bytes @ 512 (DF) > > freeboy.nfs > sunny.9dca8c95: reply ok 116 readdir ERROR: 'Unknown error: 10003' > > 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.) You are spot on. The calls to getdents are supplying stale cookies to the server and the server is telling them to get lost. The client is supposed to recover from this be re-reading the directory. Coping with this situation properly is not as easy as it looks. A naive NFS client implementation would store the cookie for the last entry read as the seek offset in the file. It would then give that cookie to the server next time to restart the read. This is the algorithm used in 2.1.7 and is sufficient for NFSv2 in most cases. This only works if the cookie bears a strong resemblance to a seek offset itself. I can imagine plenty of possible server implementations where this is not the case. The FreeBSD client reads directory entries into bufs. These entries have a different packing in the buf from the server so the offset of a particular buf bears little resemblance to the offset in the server's directory. It also builds a mapping in the nfsnode which maps an offset (only supporting offsets to the start of a buffer boundary) to the cookie needed to re-read the contents of that buf. If the cookies are rejected by the server, it simply re-reads from the start of the directory and rebuilds its logical (buffer offset) to physical (nfs cookie) mapping. The file offset used by getdirentries is an offset into the logical mapping of the client's cache. -- Doug Rabson, Microsoft RenderMorphics Ltd. Mail: dfr@render.com Phone: +44 171 734 3761 These are not the opinions of Microsoft. FAX: +44 171 734 6426
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?sek9nd71zp.fsf>