All of lore.kernel.org
 help / color / mirror / Atom feed
From: Josef Bacik <josef@toxicpanda.com>
To: linux-btrfs@vger.kernel.org, kernel-team@fb.com
Subject: [PATCH 0/3] Rework fs error handling
Date: Thu, 20 May 2021 11:21:30 -0400	[thread overview]
Message-ID: <cover.1621523846.git.josef@toxicpanda.com> (raw)

Hello,

This series brings together 3 patches I had sent separately, because they mostly
depend on eachother.  The first is

	btrfs: always abort the transaction if we abort a trans handle

Which changes our behavior for trans handles that haven't modified any metadata.
Our dependency chain can be complex, and thus we may rely on a particular async
action happening and rely on the transaction actually aborting if it fails.
Previously if nothing occurred we'd just let the transaction conitue, but this
could put us in a bad state.  We need to simply always abort the transaction for
safety reasons.

That patch allows us to use the next patch

	btrfs: add a btrfs_has_fs_error helper

Now that we can rely on FS_STATE_ERROR always being set if something is wrong,
we can wrap that check in a helper and convert all the open coded checks for
FS_STATE_ERROR and FS_STATE_ABORTED to the new helper.

And finally an actual fix

	btrfs: do not infinite loop in data reclaim if we aborted

The async data path could infinite loop if we aborted because it only broke in
the case of space_info->full, which would never happen if we weren't full and
had aborted the transaction.  This is fine stand alone, but I took advantage of
the helpers here so I want to make sure the fix goes along with its
dependencies.  Thanks,

Josef

Josef Bacik (3):
  btrfs: always abort the transaction if we abort a trans handle
  btrfs: add a btrfs_has_fs_error helper
  btrfs: do not infinite loop in data reclaim if we aborted

 fs/btrfs/ctree.c       |  5 +----
 fs/btrfs/ctree.h       |  5 +++++
 fs/btrfs/disk-io.c     |  8 +++-----
 fs/btrfs/extent-tree.c |  1 -
 fs/btrfs/extent_io.c   |  2 +-
 fs/btrfs/file.c        |  2 +-
 fs/btrfs/inode.c       |  6 +++---
 fs/btrfs/scrub.c       |  2 +-
 fs/btrfs/space-info.c  | 29 ++++++++++++++++++++++++-----
 fs/btrfs/super.c       | 13 +------------
 fs/btrfs/transaction.c | 19 +++++--------------
 fs/btrfs/transaction.h |  1 -
 fs/btrfs/tree-log.c    |  2 +-
 13 files changed, 46 insertions(+), 49 deletions(-)

-- 
2.26.3


             reply	other threads:[~2021-05-20 15:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-05-20 15:21 Josef Bacik [this message]
2021-05-20 15:21 ` [PATCH 1/3] btrfs: always abort the transaction if we abort a trans handle Josef Bacik
2021-05-25 15:27   ` David Sterba
2021-05-20 15:21 ` [PATCH 2/3] btrfs: add a btrfs_has_fs_error helper Josef Bacik
2021-05-25 15:34   ` David Sterba
2021-09-27 17:52     ` Josef Bacik
2021-05-20 15:21 ` [PATCH 3/3] btrfs: do not infinite loop in data reclaim if we aborted Josef Bacik
2021-05-25 15:39 ` [PATCH 0/3] Rework fs error handling David Sterba

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=cover.1621523846.git.josef@toxicpanda.com \
    --to=josef@toxicpanda.com \
    --cc=kernel-team@fb.com \
    --cc=linux-btrfs@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.