From: "Talpey, Thomas" Subject: Re: RPC retransmission of write requests containing bogus data Date: Fri, 17 Oct 2008 09:51:01 -0400 Message-ID: References: <1224241273.9053.109.camel@zakaz.uk.xensource.com> <1224250599.7722.17.camel@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Cc: Ian Campbell , linux-nfs@vger.kernel.org, mchan-dY08KVG/lbpWk0Htik3J/w@public.gmane.org To: Trond Myklebust Return-path: Received: from mx2.netapp.com ([216.240.18.37]:37615 "EHLO mx2.netapp.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753855AbYJQNv5 (ORCPT ); Fri, 17 Oct 2008 09:51:57 -0400 In-Reply-To: <1224250599.7722.17.camel@localhost> References: <1224241273.9053.109.camel-o4Be2W7LfRlXesXXhkcM7miJhflN2719@public.gmane.org> <1224250599.7722.17.camel@localhost> Sender: linux-nfs-owner@vger.kernel.org List-ID: At 09:36 AM 10/17/2008, Trond Myklebust wrote: >On Fri, 2008-10-17 at 09:32 -0400, Talpey, Thomas wrote: >> The fix here is to break the connection before retrying, a long-standing >> pet peeve of mine that NFSv3 historically does not do. > >It's not a perfect fix, which is why we haven't done that for NFSv3. > >When you break the connection, there is the chance that a reply to a >non-idempotent request may get lost, and that the server doesn't >recognise the retransmission due to the above mentioned imperfections >with the replay cache. In that case, the client may get a downright >_wrong_ reply (for instance, it may see an EEXIST reply to a mkdir >request that was actually successful). Well, the NFSv4 client will suffer the same issue in the above case. So, it's choose your poison. The antidote is to adopt NFSv4.1 asap. ;-) Sorry about the crossing replies btw. My own transmission was scheduled before pulling email to look for other replies! Hmm... Tom.