From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ipmail06.adl2.internode.on.net ([150.101.137.129]:14122 "EHLO ipmail06.adl2.internode.on.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752291AbeDRX7x (ORCPT ); Wed, 18 Apr 2018 19:59:53 -0400 Date: Thu, 19 Apr 2018 09:59:50 +1000 From: Dave Chinner To: Andres Freund Cc: Matthew Wilcox , Jeff Layton , lsf-pc , Andreas Dilger , "Theodore Y. Ts'o" , Ext4 Developers List , Linux FS Devel , "Joshua D. Drake" Subject: Re: fsync() errors is unsafe and risks data loss Message-ID: <20180418235950.GE27893@dastard> References: <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> <20180414020433.7qltvtkipsz2pm5s@alap3.anarazel.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180414020433.7qltvtkipsz2pm5s@alap3.anarazel.de> Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On Fri, Apr 13, 2018 at 07:04:33PM -0700, Andres Freund wrote: > 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//error/metadata//... > > > > 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//error/writeback//....) > > Have you considered adding an ext/fat/jfs > errors=remount-ro/panic/continue style mount parameter? That's for metadata writeback error behaviour, not data writeback IO errors. We are definitely not planning to add mount options to configure IO error behaviors. Mount options are a horrible way to configure filesystem behaviour and we've already got other, fine-grained configuration infrastructure for configuring IO error behaviour. Which, as I just pointed out, was designed to be be extended to data writeback and other operational error handling in the filesystem (e.g. dealing with ENOMEM in different ways). Cheers, Dave. -- Dave Chinner david@fromorbit.com