On Mon, Feb 27 2017, Andreas Dilger wrote: > > My thought is that PG_error is definitely useful for applications to get > correct errors back when doing write()/sync_file_range() so that they know > there is an error in the data that _they_ wrote, rather than receiving an > error for data that may have been written by another thread, and in turn > clearing the error from another thread so it *doesn't* know it had a write > error. It might be useful in that way, but it is not currently used that way. Such usage would be a change in visible behaviour. sync_file_range() calls filemap_fdatawait_range(), which calls filemap_check_errors(). If there have been any errors in the file recently, inside or outside the range, the latter will return an error which will propagate up. > > As for stray sync() clearing PG_error from underneath an application, that > shouldn't happen since filemap_fdatawait_keep_errors() doesn't clear errors > and is used by device flushing code (fdatawait_one_bdev(), wait_sb_inodes()). filemap_fdatawait_keep_errors() calls __filemap_fdatawait_range() which clears PG_error on every page. What it doesn't do is call filemap_check_errors(), and so doesn't clear AS_ENOSPC or AS_EIO. NeilBrown
Attachment:
signature.asc
Description: PGP signature
