Messages in this thread | | | From | NeilBrown <> | Date | Tue, 28 Feb 2017 10:32:34 +1100 | Subject | Re: [LSF/MM TOPIC] do we really need PG_error at all? |
| |
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 [unhandled content-type:application/pgp-signature] | |