Received: by 2002:ac0:a5a6:0:0:0:0:0 with SMTP id m35-v6csp1270515imm; Wed, 26 Sep 2018 14:51:23 -0700 (PDT) X-Google-Smtp-Source: ACcGV620Ft7NuLnIIgTzKQe+83lV61tVVgyzQl3oxLvxNeF2anSresAhjWxZ9P2F2w4RttOMYUVp X-Received: by 2002:a65:4849:: with SMTP id i9-v6mr7192108pgs.350.1537998683230; Wed, 26 Sep 2018 14:51:23 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1537998683; cv=none; d=google.com; s=arc-20160816; b=IOnCeyJ1CAVbSVpu12I6cblgITzOG/5fN4NwiNNM0mnTh01wslfcHbQjF8eFvXfbl3 Qe8GZ4iv/KQiS76cYBTHbkegidKceFmXMUukf3mpbnhILDhud0FqehVS7XHg5qteNGNs NZtblfMuD1zmKqMF2vJbVfAfjUyLux3djpNIuwPDZc8cDt5FjXoTtY/TXzj1xzwGS3d/ wXccMeS6PytO42wz0KV0T+FyMWuTif2JytWsf5M2y2FPALYOYVURkwnB+h4Xp6cf5vws 48TDOHmAseT69wXhOurNKXKYQ5HrT6ONwluVXsX+VjrMcIUj02oi4IjFAlB5Ee0JmW0t hZZA== 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:mail-followup-to :message-id:subject:cc:to:from:date:dkim-signature; bh=GRZprxFXcbKqU+L2n25Xv70Vwzf3X9am1NryaUTfL7k=; b=HCBgEVWYbXTRyKooiS/vMHe4mpEXxF1M6NtBWF9ARnk3AADZR0Taiqq3tXRzBGLos2 WX23Nf4kUMW8JGSfSNjhXWitD2G9Z6JZZpqGY8GIAA1hZDyxt9SM1hDQU6TPE8g8JT/b exBPZFJGE+0DbsLMgqZRHxm4we87V1r2X7zIYjK/ljdLkyWp56T5gScmru7hY//LD8fE r5MGm3wmB8lJiE+0sfbyrruz8N58nJAPcbGKzuG8eAbyE8L2eWYixIFYF+XBF9rcj0xr FBuzek3zxgo24JIk4sGStrRwptF5d9XjQTIyaCPc4cwjmvelxo5wuZ31uq89MFY0EkDT AiIw== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=ctxBLxGy; 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 m16-v6si134814pgl.462.2018.09.26.14.51.08; Wed, 26 Sep 2018 14:51:23 -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; dkim=fail header.i=@thunk.org header.s=ef5046eb header.b=ctxBLxGy; 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 S1726581AbeI0EEP (ORCPT + 99 others); Thu, 27 Sep 2018 00:04:15 -0400 Received: from imap.thunk.org ([74.207.234.97]:52292 "EHLO imap.thunk.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726055AbeI0EEO (ORCPT ); Thu, 27 Sep 2018 00:04:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=thunk.org; s=ef5046eb; h=In-Reply-To:Content-Type:MIME-Version:References:Message-ID: Subject:Cc:To:From:Date:Sender:Reply-To:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=GRZprxFXcbKqU+L2n25Xv70Vwzf3X9am1NryaUTfL7k=; b=ctxBLxGyHq17Yso3B2vhMjBoyu zJX2WjuRkuKnkRuUJcmn+R6CXOEdT6bUv76F28BNXhfqM46aFXn69ujTdN3vC5zS4Aaeoe7vcgyLu 28XT5Y9CeX/r39P0areMr3KdBYyaxXxoivq4v4I3hReNh8e+wRZHJq5VfVLoCDqbUlgA=; Received: from root (helo=callcc.thunk.org) by imap.thunk.org with local-esmtp (Exim 4.89) (envelope-from ) id 1g5HgE-00042a-43; Wed, 26 Sep 2018 21:49:10 +0000 Received: by callcc.thunk.org (Postfix, from userid 15806) id 5D3227A5186; Wed, 26 Sep 2018 17:49:09 -0400 (EDT) Date: Wed, 26 Sep 2018 17:49:09 -0400 From: "Theodore Y. Ts'o" To: Alan Cox 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: <20180926214909.GD3688@thunk.org> Mail-Followup-To: "Theodore Y. Ts'o" , Alan Cox , Jeff Layton , =?utf-8?B?54Sm5pmT5Yas?= , linux-fsdevel@vger.kernel.org, linux-kernel@vger.kernel.org, Rogier Wolff 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180926191055.6fc1514f@alans-desktop> User-Agent: Mutt/1.10.1 (2018-07-13) X-SA-Exim-Connect-IP: X-SA-Exim-Mail-From: tytso@thunk.org X-SA-Exim-Scanned: No (on imap.thunk.org); SAEximRunCond expanded to false Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. There are plenty of other dependencies besides read --- for example, if you write a mp3 file, and then write the playlist.m3u file, maybe the barrier requirement is "if playlist.m3u survives after the crash, all of the mp3 files mentioned in it must completely written out to disk". So I'm not sure how useful a fbarrier(2) would be in practice. > 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? - Ted