Re: [LSF/MM TOPIC] improving writeback error handling

[Dave Chinner <david@fromorbit.com>]

On Tue, Apr 17, 2018 at 07:08:01AM -0400, Jeff Layton wrote:
> I'd like to have a discussion on how to improve the handling of errors
> that occur during writeback. I think there are 4 main issues that would
> be helpful to cover:
> 
> 1) In v4.16, we added the errseq mechanism to the kernel to make
> writeback error reporting more reliable. That has helped some use cases,
> but there are some applications (e.g. PostgreSQL) that were relying on
> the ability to see writeback errors that occurred before the file
> description existed. Do we need to tweak this mechanism to help those
> use cases, or would that do more harm than good?

More harm than good, IMO. Too many wacky corner cases...

> 2) Most filesystems report data wb errors on all fds that were open at
> the time of the error now, but metadata writeback can also fail, and
> those don't get reported in the same way so far. Should we extend those
> semantics to metadata writeback? How do we get there if so?

No. Metadata writeback errors are intimately related to internal
filesystem consistency - if there's a problem with metadata
writeback, it's up to the filesystem to determine if fsync needs to
report it or not.

And, FWIW, journalling filesystems will follow their global "fatal
error" shutdown configuration if there's  fatal metadata writeback
error. Such an error is essentially filesystem corruption, so once
this error condition is set, any subsequent attempt to fsync or
modify the filesystem should return errors (i.e. EIO or
EFSCORRUPTED).

> 3) The question of what to do with pages in the pagecache that fail
> writeback is still unresolved. Most filesystems just clear the dirty bit
> and and carry on, but some invalidate them or just clear the uptodate
> bit. This sort of inconsistency (and lack of documentation) is
> problematic and has led to applications assuming behavior that doesn't
> exist. I believe we need to declare an "ideal behavior" for Linux
> filesystems in this regard, add VM/FS helpers to make it easier for
> filesystems to conform to that behavior, and document it well. The big
> question is : what sort of behavior makes the most sense here?

User configurable on a per-filesystem basis, just like metadata
error handling. The default should be what is best for system
stability when users do things like pull USB sticks with GB of dirty
data still in memory.

> 4) syncfs doesn't currently report an error when a single inode fails
> writeback, only when syncing out the block device. Should it report
> errors in that case as well?

Yes.

And there's more than that. the filesystem ->sync_fs() method also
needs to return an error because that's where most fileystems
persist their metadata. And because sync_fs has historically thrown
the error returned away, most filesystems don't bother checking or
returning errors.

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com