Received: by 2002:a25:8b12:0:0:0:0:0 with SMTP id i18csp888649ybl; Wed, 28 Aug 2019 06:49:07 -0700 (PDT) X-Google-Smtp-Source: APXvYqzn/yjzo8w33/hR0FeWsyZhY2CRATdYKamQqWAEJnlx0oqIIt6d9YqQE/HsJ9NQM4DEmKU3 X-Received: by 2002:a17:902:7446:: with SMTP id e6mr3086334plt.307.1567000147208; Wed, 28 Aug 2019 06:49:07 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1567000147; cv=none; d=google.com; s=arc-20160816; b=kH4FaX/mS4SwJElky5S3yrPvK9iurg7mRZUFhdDkFLSa/Quu4pI0PJOjCjqFe9ELU0 EWhQpYk5aJIYaJVEYT32jBf0L2rr9tbj+i5d5tUrhTkzbQzAT+LIuj+un6RJRNPL9vlo eWKeoYulDIAzJWVPKPvN294Uopfb565E3C72OUDtcI6MZdQmYlQdRqAk79Y8rBTQQKsh PY0rl4Gut6WDP3ouIZGvOMYk6uWhrl2ntk5OoABJc97S8sleMZD8+GY4n+QsBX93s78Q NzYvBRufqhyFGreDq6ARLJEz18GcesjVfL1kkarDU+bOSqzz5m0qQAGIBY91rPfoXrAC bv3g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date; bh=ZvZGwLHZRMhLaM25pFOCJsYfWuXsMDPvh0i2Po4Bwq8=; b=WA/1dPmg4FgLI2hiMN2LsgzKxIPcklyedesxsgFiE2ORj9OFpev6tgGJcLTpt/NyKu 0ROj/EKGkI0P+r08afXu0ylCJPMCNczksaMMBTinG1p2YDLzLUpEXKRcHL5dD9+hyeST RjSnorXAIu0LHdx8fzuQiKBpGl6+pUhYXKG4mgXOIl44EE0IH//XbjTt9npBlvDk6fYL MK9RN/jLQlzGDpmUVFFyyQqm8+SchSNfTMm9Xa99GUz2Y57iAXKvtNw2Ic8uOP2kqfjN 04o2gUw22C44lwdPak3ifueQ3xv9Laq0pEcSLP28ZUqCdSJSbJpjZ7DUGw5LK36TAXty ZGpw== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id g17si2108557pgd.357.2019.08.28.06.48.43; Wed, 28 Aug 2019 06:49:07 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-nfs-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726410AbfH1Nsj (ORCPT + 99 others); Wed, 28 Aug 2019 09:48:39 -0400 Received: from fieldses.org ([173.255.197.46]:48940 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726407AbfH1Nsj (ORCPT ); Wed, 28 Aug 2019 09:48:39 -0400 Received: by fieldses.org (Postfix, from userid 2815) id 53BED7CC; Wed, 28 Aug 2019 09:48:39 -0400 (EDT) Date: Wed, 28 Aug 2019 09:48:39 -0400 From: "bfields@fieldses.org" To: Trond Myklebust Cc: "jlayton@redhat.com" , "linux-nfs@vger.kernel.org" , "bfields@redhat.com" , "chuck.lever@oracle.com" , "jlayton@poochiereds.net" Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd Message-ID: <20190828134839.GA26492@fieldses.org> References: <20190826165021.81075-1-trond.myklebust@hammerspace.com> <20190826205156.GA27834@fieldses.org> <61F77AD6-BD02-4322-B944-0DC263EB9BD8@oracle.com> <20190827145819.GB9804@fieldses.org> <20190827145912.GC9804@fieldses.org> <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ee75165d548b336f5724b6d655aa2545b9270c3.camel@hammerspace.com> 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 Tue, Aug 27, 2019 at 03:15:35PM +0000, Trond Myklebust wrote: > I'm open to other suggestions, but I'm having trouble finding one that > can scale correctly (i.e. not require per-client tracking), prevent > silent corruption (by causing clients to miss errors), while not > relying on optional features that may not be implemented by all NFSv3 > clients (e.g. per-file write verifiers are not implemented by *BSD). > > That said, it seems to me that to do nothing should not be an option, > as that would imply tolerating silent corruption of file data. So should we increment the boot verifier every time we discover an error on an asynchronous write? --b.