From: fdmanana@kernel.org
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 4/8] btrfs: do not abort transaction on failure to write log tree when syncing log
Date: Tue, 10 Jan 2023 14:56:37 +0000 [thread overview]
Message-ID: <bd9231ea9024932a1c3da15d3e130f50fc2f9086.1673361215.git.fdmanana@suse.com> (raw)
In-Reply-To: <cover.1673361215.git.fdmanana@suse.com>
From: Filipe Manana <fdmanana@suse.com>
When syncing the log, if we fail to write log tree extent buffers, we mark
the log for a full commit and abort the transaction. However we don't need
to abort the transaction, all we really need to do is to make sure no one
can commit a superblock pointing to new log tree roots. Just because we
got a failure writing extent buffers for a log tree, it does not mean we
will also fail to do a transaction commit.
One particular case is if due to a bug somewhere, when writing log tree
extent buffers, the tree checker detects some corruption and the writeout
fails because of that. Aborting the transaction can be very disruptive for
a user, specially if the issue happened on a root filesystem. One example
is the scenario in the Link tag below, where an isolated corruption on log
tree leaves was causing transaction aborts when syncing the log.
Link: https://lore.kernel.org/linux-btrfs/ae169fc6-f504-28f0-a098-6fa6a4dfb612@leemhuis.info/
Signed-off-by: Filipe Manana <fdmanana@suse.com>
---
fs/btrfs/disk-io.c | 9 ++++++++-
fs/btrfs/tree-log.c | 2 --
2 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index a7d5a3967ba0..7586a8e9b718 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -367,7 +367,14 @@ static int csum_one_extent_buffer(struct extent_buffer *eb)
btrfs_print_tree(eb, 0);
btrfs_err(fs_info, "block=%llu write time tree block corruption detected",
eb->start);
- WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG));
+ /*
+ * Be noisy if this is an extent buffer from a log tree. We don't abort
+ * a transaction in case there's a bad log tree extent buffer, we just
+ * fallback to a transaction commit. Still we want to know when there is
+ * a bad log tree extent buffer, as that may signal a bug somewhere.
+ */
+ WARN_ON(IS_ENABLED(CONFIG_BTRFS_DEBUG) ||
+ btrfs_header_owner(eb) == BTRFS_TREE_LOG_OBJECTID);
return ret;
}
diff --git a/fs/btrfs/tree-log.c b/fs/btrfs/tree-log.c
index afad44a0becf..1f70d4ebffae 100644
--- a/fs/btrfs/tree-log.c
+++ b/fs/btrfs/tree-log.c
@@ -2980,7 +2980,6 @@ int btrfs_sync_log(struct btrfs_trans_handle *trans,
ret = 0;
if (ret) {
blk_finish_plug(&plug);
- btrfs_abort_transaction(trans, ret);
btrfs_set_log_full_commit(trans);
mutex_unlock(&root->log_mutex);
goto out;
@@ -3112,7 +3111,6 @@ int btrfs_sync_log(struct btrfs_trans_handle *trans,
goto out_wake_log_root;
} else if (ret) {
btrfs_set_log_full_commit(trans);
- btrfs_abort_transaction(trans, ret);
mutex_unlock(&log_root_tree->log_mutex);
goto out_wake_log_root;
}
--
2.35.1
next prev parent reply other threads:[~2023-01-10 14:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-10 14:56 [PATCH 0/8] btrfs: some log tree fixes and cleanups fdmanana
2023-01-10 14:56 ` [PATCH 1/8] btrfs: fix missing error handling when logging directory items fdmanana
2023-01-10 14:56 ` [PATCH 2/8] btrfs: fix directory logging due to race with concurrent index key deletion fdmanana
2023-01-10 14:56 ` [PATCH 3/8] btrfs: add missing setup of log for full commit at add_conflicting_inode() fdmanana
2023-01-10 14:56 ` fdmanana [this message]
2023-01-10 14:56 ` [PATCH 5/8] btrfs: do not abort transaction on failure to update log root fdmanana
2023-01-10 14:56 ` [PATCH 6/8] btrfs: simplify update of last_dir_index_offset when logging a directory fdmanana
2023-01-31 17:42 ` Filipe Manana
2023-02-06 18:40 ` David Sterba
2023-01-10 14:56 ` [PATCH 7/8] btrfs: use a negative value for BTRFS_LOG_FORCE_COMMIT fdmanana
2023-01-10 14:56 ` [PATCH 8/8] btrfs: use a single variable to track return value for log_dir_items() fdmanana
2023-01-11 21:24 ` [PATCH 0/8] btrfs: some log tree fixes and cleanups Josef Bacik
2023-01-12 14:45 ` 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=bd9231ea9024932a1c3da15d3e130f50fc2f9086.1673361215.git.fdmanana@suse.com \
--to=fdmanana@kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).