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  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]
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