[PATCH v2] btrfs: mark ordered extent and inode with error if we fail to finish

[PATCH v2] btrfs: mark ordered extent and inode with error if we fail to finish

[Josef Bacik]

While doing error injection testing I saw that sometimes we'd get an
abort that wouldn't stop the current transaction commit from completing.
This abort was coming from finish ordered IO, but at this point in the
transaction commit we should have gotten an error and stopped.

It turns out the abort came from finish ordered io while trying to write
out the free space cache.  It occurred to me that any failure inside of
finish_ordered_io isn't actually raised to the person doing the writing,
so we could have any number of failures in this path and think the
ordered extent completed successfully and the inode was fine.

Fix this by marking the ordered extent with BTRFS_ORDERED_IOERR, and
marking the mapping of the inode with mapping_set_error, so any callers
that simply call fdatawait will also get the error.

With this we're seeing the IO error on the free space inode when we fail
to do the finish_ordered_io.

Signed-off-by: Josef Bacik <josef@toxicpanda.com>
---
v1->v2:
- Wang Yugui noticed that this failed with btrfs/146, this is because we had
  already marked the mapping with the error when writeback failed, so we were
  double marking the mapping with an error and thus getting an extra report of
  the error.  Fix this by only setting the mapping error if we're the first ones
  to set ORDERED_IOERR.

 fs/btrfs/inode.c | 13 +++++++++++++
 1 file changed, 13 insertions(+)

diff --git a/fs/btrfs/inode.c b/fs/btrfs/inode.c
index 955d0f5849e3..32a62ec4f127 100644
--- a/fs/btrfs/inode.c
+++ b/fs/btrfs/inode.c
@@ -3000,6 +3000,19 @@ static int btrfs_finish_ordered_io(struct btrfs_ordered_extent *ordered_extent)
 	if (ret || truncated) {
 		u64 unwritten_start = start;
 
+		/*
+		 * If we failed to finish this ordered extent for any reason we
+		 * need to make sure BTRFS_ORDERED_IOERR is set on the ordered
+		 * extent, and mark the inode with the error if it wasn't
+		 * already set.  Any error during writeback would have already
+		 * set the mapping error, so we need to set it if we're the ones
+		 * marking this ordered extent as failed.
+		 */
+		if (ret && !test_and_set_bit(BTRFS_ORDERED_IOERR,
+					     &ordered_extent->flags))
+			mapping_set_error(ordered_extent->inode->i_mapping,
+					  -EIO);
+
 		if (truncated)
 			unwritten_start += logical_len;
 		clear_extent_uptodate(io_tree, unwritten_start, end, NULL);
-- 
2.26.3

Re: [PATCH v2] btrfs: mark ordered extent and inode with error if we fail to finish

[David Sterba]

On Wed, May 19, 2021 at 09:38:27AM -0400, Josef Bacik wrote:
> While doing error injection testing I saw that sometimes we'd get an
> abort that wouldn't stop the current transaction commit from completing.
> This abort was coming from finish ordered IO, but at this point in the
> transaction commit we should have gotten an error and stopped.
> 
> It turns out the abort came from finish ordered io while trying to write
> out the free space cache.  It occurred to me that any failure inside of
> finish_ordered_io isn't actually raised to the person doing the writing,
> so we could have any number of failures in this path and think the
> ordered extent completed successfully and the inode was fine.
> 
> Fix this by marking the ordered extent with BTRFS_ORDERED_IOERR, and
> marking the mapping of the inode with mapping_set_error, so any callers
> that simply call fdatawait will also get the error.
> 
> With this we're seeing the IO error on the free space inode when we fail
> to do the finish_ordered_io.
> 
> Signed-off-by: Josef Bacik <josef@toxicpanda.com>

Added to misc-next, thanks.