From owner-freebsd-current@FreeBSD.ORG Mon Nov 26 12:58:30 2007 Return-Path: Delivered-To: freebsd-current@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id EE25916A417; Mon, 26 Nov 2007 12:58:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id C0C4C13C46E; Mon, 26 Nov 2007 12:58:30 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 28A09471F5; Mon, 26 Nov 2007 08:02:04 -0500 (EST) Date: Mon, 26 Nov 2007 12:58:23 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86ir3p4203.fsf@ds4.des.no> Message-ID: <20071126125413.U65286@fledge.watson.org> 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> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-1674026014-1196081903=:65286" Cc: Timo Sirainen , freebsd-current@FreeBSD.org, Adam McDougall , mohans@FreeBSD.org Subject: Re: link() not increasing link count on NFS server X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2007 12:58:31 -0000 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 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--