Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1076141imm; Wed, 26 Sep 2018 11:12:32 -0700 (PDT) X-Google-Smtp-Source: ACcGV61vP0je8uTAl2hoywe8ugCPEfnit3xhlbnYCIwSarafHs8qY5/BcLExjhMWGaFAsHN0ySKX X-Received: by 2002:a63:350f:: with SMTP id c15-v6mr6684790pga.206.1537985552000; Wed, 26 Sep 2018 11:12:32 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537985551; cv=none; d=google.com; s=arc-20160816; b=GbAzwGVRvHxMSdP0m+yFJ4k3P89Pu9+5kM0z6IUvANRWQrxPkZk6f5hF3LE2OigrQ1 1xKUu73xYHrgNOuvjIX2F4d53ehu8FvhzeL6AJ6OTnzc4e0dtLpgW2h4vcv/c0DPl4m4 V6TOO9lkuPMo8kbXt63+sYtEp2XLRZinXeMYFogy+pFsRDy1+5zHRh5yol24NF+DdzXM A1g3eo//nIZ9S8OFAWgaivaERL8rwCxlxG3vM7IO/z2fs5FWhd2VJJ6bvAxWVKavEF93 +euuMcodWcbPY9g0bI1rJgW9ICJdrsdhU5mgnLEXcwk2fONgm1BxStel3wQ7eRejB9qe 1N0Q== 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=4SJNEKkTrSjPZWkAhkgtth6CWW7nQZYG04wmwQ5kS6g=; b=WKyUvqxmkCSMtiPs7SeaLq8y+L07EDn4ze2IAZRqqaRrhrK7utEK/bs64jAxlQ4D46 kkZapnHuUKk7qrX1Xg94xa9MQCmhdiVGqHyChnPu4r6UmASiePhgVm1x1csvRSCXEvtL n1HJV3vd+BsXYZi++ivVmBjnrPkobrbynhiIDZnMXiyX5vnne/ZOybp5RPtvjYh30nzE ATLU2RgfFmKbx/H9FJ8e3cU+uT1gm0LxyTtUqpeUmm6WY65SJq7g40h0nEJYtTNOrGko yfPVV8U5V4eZK9mXdqCn+SD8KELeCNYV3lsweYOW0Vp3bt3/e8MZmudpvTnxfaEBk91Z e+aQ== 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 h7-v6si5290024plt.21.2018.09.26.11.12.15; Wed, 26 Sep 2018 11:12:31 -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 S1728492AbeI0AZQ (ORCPT + 99 others); Wed, 26 Sep 2018 20:25:16 -0400 Received: from www.llwyncelyn.cymru ([82.70.14.225]:52676 "EHLO fuzix.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726410AbeI0AZQ (ORCPT ); Wed, 26 Sep 2018 20:25:16 -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 w8QIAuC3031360; Wed, 26 Sep 2018 19:10:56 +0100 Date: Wed, 26 Sep 2018 19:10:55 +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: <20180926191055.6fc1514f@alans-desktop> In-Reply-To: <20180925223054.GH2933@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> 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 > And I think that's fine. The only way we can make any guarantees is > if we do what Alan suggested, which is to imply that a read on a dirty > page *block* until the the page is successfully written back. This > would destroy performance. 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. 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' Alan