From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from bombadil.infradead.org ([198.137.202.133]:35786 "EHLO
        bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1752486AbeDLVYi (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Thu, 12 Apr 2018 17:24:38 -0400
Date: Thu, 12 Apr 2018 14:24:32 -0700
From: Matthew Wilcox <willy@infradead.org>
To: "Theodore Y. Ts'o" <tytso@mit.edu>
Cc: Andres Freund <andres@anarazel.de>,
        Dave Chinner <david@fromorbit.com>,
        Jeff Layton <jlayton@redhat.com>,
        Andreas Dilger <adilger@dilger.ca>,
        20180410184356.GD3563@thunk.org,
        Ext4 Developers List <linux-ext4@vger.kernel.org>,
        Linux FS Devel <linux-fsdevel@vger.kernel.org>,
        "Joshua D. Drake" <jd@commandprompt.com>
Subject: Re: fsync() errors is unsafe and risks data loss
Message-ID: <20180412212432.GE18364@bombadil.infradead.org>
References: <20180410220726.vunhvwuzxi5bm6e5@alap3.anarazel.de>
 <190CF56C-C03D-4504-8B35-5DB479801513@dilger.ca>
 <20180412021752.2wykkutkmzh4ikbf@alap3.anarazel.de>
 <20180412030248.GA8509@bombadil.infradead.org>
 <1523531354.4532.21.camel@redhat.com>
 <20180412120122.GE23861@dastard>
 <20180412151646.GQ2801@thunk.org>
 <20180412201322.77igwnxfqbmnsxkf@alap3.anarazel.de>
 <20180412202830.GA18364@bombadil.infradead.org>
 <20180412212144.GV2801@thunk.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180412212144.GV2801@thunk.org>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Apr 12, 2018 at 05:21:44PM -0400, Theodore Y. Ts'o wrote:
> On Thu, Apr 12, 2018 at 01:28:30PM -0700, Matthew Wilcox wrote:
> > On Thu, Apr 12, 2018 at 01:13:22PM -0700, Andres Freund wrote:
> > > I think a per-file or even per-blockdev/fs error state that'd be
> > > returned by fsync() would be more than sufficient.
> > 
> > Ah; this was my suggestion to Jeff on IRC.  That we add a per-superblock
> > wb_err and then allow syncfs() to return it.  So you'd open an fd on
> > a directory (for example), and call syncfs() which would return -EIO
> > or -ENOSPC if either of those conditions had occurred since you opened
> > the fd.
> 
> When or how would the per-superblock wb_err flag get cleared?

That's not how errseq works, Ted ;-)

> Would all subsequent fsync() calls on that file system now return EIO?
> Or would only all subsequent syncfs() calls return EIO?

Only ones which occur after the last sampling get reported through this
particular file descriptor.