linux-ext4 - Re: fsync() errors is unsafe and risks data loss

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20180418235950.GE27893@dastard>
Date:   Thu, 19 Apr 2018 09:59:50 +1000
From:   Dave Chinner <david@...morbit.com>
To:     Andres Freund <andres@...razel.de>
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

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/<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?

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@...morbit.com