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
next 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.