From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mx1.redhat.com ([209.132.183.28]:53302 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752326AbeDSAXu (ORCPT ); Wed, 18 Apr 2018 20:23:50 -0400 Reply-To: sandeen@redhat.com Subject: Re: fsync() errors is unsafe and risks data loss To: Dave Chinner , Andres Freund Cc: Matthew Wilcox , Jeff Layton , lsf-pc , Andreas Dilger , "Theodore Y. Ts'o" , Ext4 Developers List , Linux FS Devel , "Joshua D. Drake" 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> <20180418235950.GE27893@dastard> From: Eric Sandeen Message-ID: Date: Wed, 18 Apr 2018 19:23:46 -0500 MIME-Version: 1.0 In-Reply-To: <20180418235950.GE27893@dastard> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Sender: linux-fsdevel-owner@vger.kernel.org List-ID: On 4/18/18 6:59 PM, Dave Chinner wrote: > 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. /me points casually at data_err=abort & data_err=ignore in ext4... data_err=ignore Just print an error message if an error occurs in a file data buffer in ordered mode. data_err=abort Abort the journal if an error occurs in a file data buffer in ordered mode. Just sayin' > 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). I don't disagree, but there are already mount-option knobs in ext4, FWIW. -Eric > Cheers, > > Dave. >