From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from out3-smtp.messagingengine.com ([66.111.4.27]:50593 "EHLO
        out3-smtp.messagingengine.com" rhost-flags-OK-OK-OK-OK)
        by vger.kernel.org with ESMTP id S1751141AbeDNCEf (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Fri, 13 Apr 2018 22:04:35 -0400
Date: Fri, 13 Apr 2018 19:04:33 -0700
From: Andres Freund <andres@anarazel.de>
To: Dave Chinner <david@fromorbit.com>
Cc: Matthew Wilcox <willy@infradead.org>,
        Jeff Layton <jlayton@redhat.com>,
        lsf-pc <lsf-pc@lists.linuxfoundation.org>,
        Andreas Dilger <adilger@dilger.ca>,
        "Theodore Y. Ts'o" <tytso@mit.edu>,
        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: <20180414020433.7qltvtkipsz2pm5s@alap3.anarazel.de>
References: <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>
 <1523545730.4532.82.camel@redhat.com>
 <20180412224404.GA5572@dastard>
 <1523625536.4847.21.camel@redhat.com>
 <20180413140232.GA24379@bombadil.infradead.org>
 <20180414014752.GG23861@dastard>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180414014752.GG23861@dastard>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

Hi,

On 2018-04-14 11:47:52 +1000, Dave Chinner wrote:
> And we treat different errors according to their seriousness.  EIO
> and device ENOSPC we default to retry forever because they are often
> transient, but for ENODEV we fail and shutdown immediately (someone
> pulled the USB stick out). metadata failure behaviour is configured
> via changing fields in /sys/fs/xfs/<dev>/error/metadata/<errno>/...
> 
> We've planned to extend this failure configuration to data IO, too,
> but never quite got around to it yet. this is a clear example of
> "one size doesn't fit all" and I think we'll end up doing the same
> sort of error behaviour configuration in XFS for these cases.
> (i.e. /sys/fs/xfs/<dev>/error/writeback/<errno>/....)

Have you considered adding an ext/fat/jfs
errors=remount-ro/panic/continue style mount parameter?

Greetings,

Andres Freund