From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-2.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id D06FAC3A5A1 for ; Wed, 28 Aug 2019 14:48:41 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id B10F32077B for ; Wed, 28 Aug 2019 14:48:41 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726767AbfH1Osj (ORCPT ); Wed, 28 Aug 2019 10:48:39 -0400 Received: from fieldses.org ([173.255.197.46]:49014 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726272AbfH1Osj (ORCPT ); Wed, 28 Aug 2019 10:48:39 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 177921C97; Wed, 28 Aug 2019 10:48:39 -0400 (EDT) Date: Wed, 28 Aug 2019 10:48:39 -0400 From: Bruce Fields To: "J. Bruce Fields" Cc: Jeff Layton , Chuck Lever , Trond Myklebust , Linux NFS Mailing List Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd Message-ID: <20190828144839.GA26284@fieldses.org> References: <20190827145819.GB9804@fieldses.org> <20190827145912.GC9804@fieldses.org> <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com> <20190828134839.GA26492@fieldses.org> <45582F32-69C7-4DC8-A608-E45038A44D42@oracle.com> <20190828140044.GA14249@parsley.fieldses.org> <990B7B57-53B8-4ECB-A08B-1AFD2FCE13A6@oracle.com> <31658faabfbe3b4c2925bd899e264adf501fbc75.camel@redhat.com> <20190828144031.GB14249@parsley.fieldses.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190828144031.GB14249@parsley.fieldses.org> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org On Wed, Aug 28, 2019 at 10:40:31AM -0400, J. Bruce Fields wrote: > On Wed, Aug 28, 2019 at 10:16:09AM -0400, Jeff Layton wrote: > > For the most part, these sorts of errors tend to be rare. If it turns > > out to be a problem we could consider moving the verifier into > > svc_export or something? > > As Trond says, this isn't really a server implementation issue, it's a > protocol issue. If a client detects when to resend writes by storing a > single verifier per server, then returning different verifiers from > writes to different exports will have it resending every time it writes > to one export then another. The other way to limit this is by trying to detect the single-writer case, since it's probably also rare for multiple clients to write to the same file. Are there any common cases where two clients share the same TCP connection? Maybe that would be a conservative enough test? And you wouldn't have to track every connection that's ever sent a WRITE to a given file. Just remember the first one, with a flag to track whether anyone else has ever written to it. ?? --b.