Date: Mon, 26 Nov 2007 12:58:23 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= <des@des.no> Cc: Timo Sirainen <tss@iki.fi>, freebsd-current@FreeBSD.org, Adam McDougall <mcdouga9@egr.msu.edu>, mohans@FreeBSD.org Subject: Re: link() not increasing link count on NFS server Message-ID: <20071126125413.U65286@fledge.watson.org> In-Reply-To: <86ir3p4203.fsf@ds4.des.no> References: <20071115074247.GQ37473@egr.msu.edu> <20071115123543.H82897@fledge.watson.org> <1195132320.6039.135.camel@hurina> <20071115135734.O82897@fledge.watson.org> <86ir3p4203.fsf@ds4.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-1674026014-1196081903=:65286 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Mon, 26 Nov 2007, Dag-Erling Sm=F8rgrav wrote: > Robert Watson <rwatson@FreeBSD.org> writes: >> Indeed, and inspection of nfs_vnops.c:nfs_link(): finds: >> >> 1772 /* >> 1773 * Kludge: Map EEXIST =3D> 0 assuming that it is a reply to= a retry. >> 1774 */ >> 1775 if (error =3D=3D EEXIST) >> 1776 error =3D 0; >> 1777 return (error); >> >> Neither Linux nor Solaris appears to have this logic in the client. I >> assume this is, as suggested, to work around UDP retransmissions where >> the reply is lost rather than the request. It appears to exist in >> revision 1.1 of nfs_vnops.c, so came in with 4.4BSD in the initial >> import, but doesn't appear in NetBSD so I'm guessing they've removed >> it. > > Wrong, it still exists in NetBSD, but they've separated part of nfs_link(= )=20 > (including that bit) out into nfs_linkrpc(). They also seem to have adde= d=20 > logic to detect a retransmit: > > /* > * Kludge: Map EEXIST =3D> 0 assuming that it is a reply to a retr= y. > */ > if (rexmit && error =3D=3D EEXIST) > error =3D 0; Indeed, a later post also pointed this out. > revision 1.197 date: 2004/05/10 10:40:42; author: yamt; state: Exp;=20 > lines: +32 -25 > don't do kludge for a reply to a retransmitted request unless we actually= =20 > retransmitted the request. While their workaround is better than our workaround, is there reason to=20 believe that a request is more likely to be dropped than a reply, and that= =20 their workaround is therefore better than no workaround? The case I have i= n=20 mind is the one in which EEXIST is, in fact, the expected and desirable res= ult=20 of the original request, now dropped, or the retransmitted request, which g= ets=20 through. Robert N M Watson Computer Laboratory University of Cambridge --621616949-1674026014-1196081903=:65286--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20071126125413.U65286>