Date: Sat, 12 Jan 2008 22:26:10 +0000 (GMT) From: Robert Watson <rwatson@FreeBSD.org> To: Adam McDougall <mcdouga9@egr.msu.edu> Cc: cvs-src@FreeBSD.org, src-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/nfsclient nfs_vnops.c Message-ID: <20080112222521.L36731@fledge.watson.org> In-Reply-To: <20071229061730.GY68594@egr.msu.edu> References: <200711271220.lARCKxFm040533@repoman.freebsd.org> <20071229061730.GY68594@egr.msu.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 29 Dec 2007, Adam McDougall wrote: > Can this be merged to 6 as well? I've been running the patch ported to > 6-stable for a while with no problems. Thanks. Adam, Sorry for the delay in responding -- I'll merge this to 6-STABLE after 6.3-RELEASE is over and done with. Robert N M Watson Computer Laboratory University of Cambridge > > On Tue, Nov 27, 2007 at 12:20:59PM +0000, Robert Watson wrote: > > rwatson 2007-11-27 12:20:59 UTC > > FreeBSD src repository > > Modified files: (Branch: RELENG_7) > sys/nfsclient nfs_vnops.c > Log: > Merge nfs_vnops.c:1.277 from HEAD to RELENG_7: > > Remove hacks from the NFSv2/3 client intended to handle a lack of a > server-side RPC retranmission cache for non-idempotent operations: these > hacks substituted 0 (success) for the expected EEXIST in the event that > a target name already existed for LINK, SYMLINK, and MKDIR operations, > under the assumption that EEXIST represented a second application of the > original RPC rather than a true failure. > > Background: certain NFS operations (in this case, LINK, SYMLINK, and > MKDIR) are not idempotent, as they leave behind persisting state on the > server that prevents them from being replayed without an error;if an UDP > RPC reply is lost leading to a retransmission by theclient, the second > reply will return EEXIST rather than success, asthe new object has > already been created. The NFS client previouslysilently mapped the > EEXIST return into success to paper over thisproblem. > > However, in all modern NFS server implementations, a reply cache is kept > in order to retransmit the original reply to a retransmitted request, > rather than performing the operation a second time, allowing this hack > to be avoided. This allows link()-based filelocking over NFS to operate > correctly, as an application requestingthe creation of a new link for a > file to tell if it succeededatomically or not. > > Other NFS clients, including Solaris and Linux, generally follow this > behavior for the same reasons. Most clients also now default to TCP, > which also helps avoid the issue of retransmitted but non-idempotent > requests in most cases. > > Reported by: Adam McDougall <mcdouga9 at egr dot msu dot edu>, > Timo Sirainen <tss at iki dot fi> > Reviewed by: mohans > > Approved by: re (kensmith) > > Revision Changes Path > 1.276.2.1 +4 -25 src/sys/nfsclient/nfs_vnops.c > _______________________________________________ > cvs-src@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/cvs-src > To unsubscribe, send any mail to "cvs-src-unsubscribe@freebsd.org" > >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080112222521.L36731>