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

[Dave Chinner <david@fromorbit.com>]

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