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 for Android: free password hash cracker in your pocket

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

Date:   Wed, 18 Apr 2018 19:23:46 -0500
From:   Eric Sandeen <esandeen@...hat.com>
To:     Dave Chinner <david@...morbit.com>,
        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 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/<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.

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