Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp52352imm; Thu, 27 Sep 2018 15:50:08 -0700 (PDT) X-Google-Smtp-Source: ACcGV63stSCuGC2DNGvjmNcZiHLNW8TCtU47eTiOo12ZlKQc0x0C2KMvqr6WUsRxvY4fW6bb9+FW X-Received: by 2002:a65:4385:: with SMTP id m5-v6mr2357759pgp.219.1538088608290; Thu, 27 Sep 2018 15:50:08 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1538088608; cv=none; d=google.com; s=arc-20160816; b=YDhW9tnmxDQvP0E1cpQto/78VMZDoYswu0dwOHbVzhK28sZmC/ndlZGhEuUMxO7Ine A/7t4r5rpLkDiIPMVvcQM83e4eaAPAmbHmfBKg/bS5GhER/8YNsHdS3S/LhX10eetWQf SWZ7woiBqwElRQLkc8KHWWpOlD494eCCBjH/PdMcxCKMVlhq/3+LFjceuzWGq8RGU7i2 oCPJuOTNqxUjBbqrtu99QZ7KvuNOPik1AK3d/nQ3p2AWj2N23mbqtz1dyZAvWKmPgBd4 Fqv8PEL5Sv41LIp/P6eBtyEWEgMPQuiBkVOzhrIMbbsEM4r5HoCn+/pjflyHFYzc6mp8 GE+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :organization:references:in-reply-to:message-id:subject:cc:to:from :date; bh=QEP9ektNADieauFCCNlCofrTpYyZWKTQXB3FE7Y6yXE=; b=DXI68FzOemeRA7AOtU85VjzuzLEwR+whAQQfoQmugpYdOBrI6Fqwd7HLamtxVNotp4 vK6f0zNZz4fUe7iBmEGLcf6GHuiFOdXBtoxSXDAfHxKFFVXI8EBIavsXr+8G5RI2EuXF Tylf+6Wxe0ppzKvl40/Fxlrk3YQAFVBLtpcBtsFg212v0ho89WPB/R8kNUCFAhzh7+3z NEfIdThwUBWb0Ju5nulXwWF3eWSCAtDCzaovjYoFRUofIS+WsrGAyjTsYkUJ7GOzPnA4 Bbc/haBeLhl1d2zeNnAOzbPIlUAwaK4sWqVFl/yD6+JqkXDY65Iy1UDPQR/N7rgX7zzr VJcQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-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 z6-v6si3051914pln.287.2018.09.27.15.49.52; Thu, 27 Sep 2018 15:50:08 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-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-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1728337AbeI1FJp (ORCPT + 99 others); Fri, 28 Sep 2018 01:09:45 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:58492 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726024AbeI1FJp (ORCPT ); Fri, 28 Sep 2018 01:09:45 -0400 Received: from alans-desktop (82-70-14-226.dsl.in-addr.zen.co.uk [82.70.14.226]) by fuzix.org (8.15.2/8.15.2) with ESMTP id w8RMmxLL000501; Thu, 27 Sep 2018 23:48:59 +0100 Date: Thu, 27 Sep 2018 23:48:58 +0100 From: Alan Cox To: "Theodore Y. Ts'o" Cc: Jeff Layton , =?UTF-8?B?54Sm5pmT5Yas?= , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Rogier Wolff Subject: Re: POSIX violation by writeback error Message-ID: <20180927234858.507ea60b@alans-desktop> In-Reply-To: <20180926214909.GD3688@thunk.org> References: <486f6105fd4076c1af67dae7fdfe6826019f7ff4.camel@redhat.com> <20180925003044.239531c7@alans-desktop> <0662a4c5d2e164d651a6a116d06da380f317100f.camel@redhat.com> <20180925154627.GC2933@thunk.org> <23cd68a665d27216415dc79367ffc3bee1b60b86.camel@redhat.com> <20180925223054.GH2933@thunk.org> <20180926191055.6fc1514f@alans-desktop> <20180926214909.GD3688@thunk.org> Organization: Intel Corporation X-Mailer: Claws Mail 3.16.0 (GTK+ 2.24.32; x86_64-redhat-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 26 Sep 2018 17:49:09 -0400 "Theodore Y. Ts'o" wrote: > On Wed, Sep 26, 2018 at 07:10:55PM +0100, Alan Cox wrote: > > In almost all cases you don't care so you wouldn't use it. In those cases > > where it might matter it's almost always the case that a reader won't > > consume it before it hits the media. > > > > That's why I suggested having an fbarrier() so you can explicitly say 'in > > the even that case does happen then stall and write it'. It's kind of > > lazy fsync. That can be used with almost no cost by things like mail > > daemons. > > How could mail daemons use it? They *have* to do an fsync() before > they send a 2xx SMTP return code. Point - so actually it would be less useful > > Another way given that this only really makes sense with locks > > is to add that fbarrier notion as a file locking optional semantic so you > > can 'unlock with barrier' and 'lock with barrier honoured' > > I'm not sure what you're suggesting? If someone has an actual case you could in theory constrain it to a range specified in a file lock and only between two people who care. That said seems like a lot of complexity to make a case nobody cares about only affect people who care about it Alan