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,URIBL_BLOCKED,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 CB647C3A5A3 for ; Tue, 27 Aug 2019 14:59:13 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A6B4020828 for ; Tue, 27 Aug 2019 14:59:13 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726527AbfH0O7N (ORCPT ); Tue, 27 Aug 2019 10:59:13 -0400 Received: from fieldses.org ([173.255.197.46]:47784 "EHLO fieldses.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725811AbfH0O7N (ORCPT ); Tue, 27 Aug 2019 10:59:13 -0400 Received: by fieldses.org (Postfix, from userid 2815) id BCA4E1CB3; Tue, 27 Aug 2019 10:59:12 -0400 (EDT) Date: Tue, 27 Aug 2019 10:59:12 -0400 From: "bfields@fieldses.org" To: Trond Myklebust Cc: "chuck.lever@oracle.com" , "jlayton@redhat.com" , "linux-nfs@vger.kernel.org" , "bfields@redhat.com" , "jlayton@poochiereds.net" Subject: Re: [PATCH 0/3] Handling NFSv3 I/O errors in knfsd Message-ID: <20190827145912.GC9804@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190827145819.GB9804@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 Tue, Aug 27, 2019 at 10:58:19AM -0400, bfields@fieldses.org wrote: > On Tue, Aug 27, 2019 at 02:53:01PM +0000, Trond Myklebust wrote: > > The one problem is that the looping forever client can cause other > > clients to loop forever on their otherwise successful writes on other > > files. > > Yeah, that's the case I was wondering about. > > > That's bad, but again, that's due to client behaviour that is > > toxic even today. > > So my worry was that if write errors are rare and the consequences of > the single client looping forever are relatively mild, then there might > be deployed clients that get away with that behavior. > > But maybe the behavior's a lot more "toxic" than I imagined, hence > unlikely to be very common. (And, to be clear, I like the idea, just making sure I'm not overlooking any problems....) --b.