[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180414020433.7qltvtkipsz2pm5s@alap3.anarazel.de>
Date: Fri, 13 Apr 2018 19:04:33 -0700
From: Andres Freund <andres@...razel.de>
To: Dave Chinner <david@...morbit.com>
Cc: Matthew Wilcox <willy@...radead.org>,
Jeff Layton <jlayton@...hat.com>,
lsf-pc <lsf-pc@...ts.linuxfoundation.org>,
Andreas Dilger <adilger@...ger.ca>,
"Theodore Y. Ts'o" <tytso@....edu>,
Ext4 Developers List <linux-ext4@...r.kernel.org>,
Linux FS Devel <linux-fsdevel@...r.kernel.org>,
"Joshua D. Drake" <jd@...mandprompt.com>
Subject: Re: fsync() errors is unsafe and risks data loss
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
Powered by blists - more mailing lists