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

[Eric Sandeen <esandeen@redhat.com>]

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