Date: Wed, 18 Nov 1998 09:42:51 +0100 (CET) From: Remy Nonnenmacher <remy@synx.com> To: cejkar@dcse.fee.vutbr.cz Cc: freebsd-current@FreeBSD.ORG, freebsd-hackers@FreeBSD.ORG Subject: Re: Is it soup yet? FreeBSD NFS Message-ID: <199811180847.JAA12651@rt2.synx.com> In-Reply-To: <199811180812.JAA25327@kazi.dcse.fee.vutbr.cz>
next in thread | previous in thread | raw e-mail | index | archive | help
On 18 Nov, Cejka Rudolf wrote: > > (CC: hackers) > >> On 13 Nov, Cejka Rudolf wrote: >> > >> > We have long-time problems (not critical) with NFS server running >> > on FreeBSD 2.2.6/2.2.7/3.0 against Solaris 2.5/2.6 clients there. >> > >> > Our problem: >> > >> > FreeBSD: NFS server without any special parameters. >> > Solaris: NFS client without any special parameters. >> > >> > Example - working on Solaris above mounted filesystem from FreeBSD: >> > >> > $ gzcat less-332.tar.gz | tar xvf - # This creates 74 files in >> > # directory less-332 >> > $ rm -r less-332 # This _leaves_ 43 files! >> > rm: Unable to remove directory less-332: File exists >> > $ rm -r less-332 # This _still leaves_ 15 files! >> > rm: Unable to remove directory less-332: File exists >> > $ rm -r less-332 # Uff, directory is removed now... >> > >> > I think, problem is in different versions (NFSv2 vs. NFSv3) - but it >> > looks very trivial (?). If I mount NFS exported filesystem (exports >> > FreeBSD) on Solaris with option "vers=2" (it says "use NFSv2"), >> > problems disappear. But we are using cachefs (cached filesystem) over >> > NFS with automounting feature and we have no change to say "cachefs, >> > mount NFS filesystem with 'vers=2' option". There isn't any parameter >> > for this on Solaris... >> >> I have an open problem on this (pr5890). Look at it and try the >> suggested fix. The machine where it is applied runs NFS serving for now >> 7 month and no problems appeared (clients: Solaris, aix, sco, hpux). >> >> No need to say that this needs a competent blessing....(re-read the BSD >> license before trying it :). >> >> RN. > > Yes. It looks it is the problem. Thanks. > > I have tried to debug mentioned code. Source code is: > > if (!error && toff && verf && verf != at.va_filerev) > error = NFSERR_BAD_COOKIE; > > And in case of "rm -r less-332" values for example are: > error: 0 > toff: 5c:02:00:00:00:00:00:00 (memory dump) > verf: c7:a4:7c:5a:5b:00:00:00 (memory dump) > at.va_filerev: e6:a4:7c:5a:5b:00:00:00 (memory dump) > In every next "rm -r less-332" try value in at.va_filerev goes into verf > and at.va_filerev contains new unknown value. So is this bug on > Solaris side? (Or FreeBSD?) Is there any possible workaround without > disabling COOKIE tests? > > Thanks. > > --=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=--=-- > Rudolf Cejka (cejkar@dcse.fee.vutbr.cz; http://www.fee.vutbr.cz/~cejkar) > Technical University of Brno, Faculty of El. Engineering and Comp. Science > Bozetechova 2, 612 66 Brno, Czech Republic It clearly requires a NFS' god blessing. My view of it is that the cookie identifying a directory changes after a few operations (maybe after releasing a block of free entries. May be checked by removing files in reverse scanning order ?) but client continue to use the old cookie. Reading NFS specs would say if server is wrong in changing the cookie or is the client is wrong to use an old one. I'm not competent enought to go further. "peter" at -bugs is in charge of it and, considering the NFS complexity, I assume the problem is not simple. RN. ItM To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199811180847.JAA12651>