linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [RFC PATCH] btrfs: Introduce developer-oriented check to ensure all tree blocks are written back before writing super blocks
Date: Thu, 21 Feb 2019 16:22:49 +0800	[thread overview]
Message-ID: <20190221082249.24187-1-wqu@suse.com> (raw)

There are a lot of error reports complaining about transid error in the
mail list.

Under most case, the on-disk transid is lower than expected transid.
This may indicate that some tree blocks are not written back to disk
before writing super blocks.

This patch will add a safe net for developers, by calling
btrfs_write_and_wait_transaction() before setting transaction unblocked
and double check btree_inode and dirty_pages io_tree, to ensure no tree
blocks are still dirty or under writeback.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
The reason for RFC is, I'm not sure why we currently call
btrfs_write_and_wait_transaction() after setting transaction UNBLOCKED.

It looks like an optimization, but I don't see much performance
difference during regression test.

I hope to move the call before we unblock transaction so we can do such
sanity check for all builds and hope to catch some clue of transid
error.
---
 fs/btrfs/transaction.c | 38 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 38 insertions(+)

diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c
index 4ec2b660d014..30b7ed0bf873 100644
--- a/fs/btrfs/transaction.c
+++ b/fs/btrfs/transaction.c
@@ -2213,6 +2213,44 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans)
 
 	btrfs_trans_release_chunk_metadata(trans);
 
+	/* Last safenet or developer to catch any unwritten tree blocks */
+	if (IS_ENABLED(CONFIG_BTRFS_DEBUG)) {
+		u64 found_start = 0;
+		u64 found_end = 0;
+
+		ret = btrfs_write_and_wait_transaction(trans);
+		if (ret) {
+			btrfs_handle_fs_error(fs_info, ret,
+					      "Error while writing out transaction");
+			mutex_unlock(&fs_info->tree_log_mutex);
+			goto scrub_continue;
+		}
+
+		/* No dirty extent should exist in btree inode */
+		ret = test_range_bit(&trans->transaction->dirty_pages, 0,
+				(u64)-1, EXTENT_DIRTY | EXTENT_WRITEBACK,
+				0, NULL);
+		if (ret > 0) {
+			WARN(1,
+		"dirty_pages not fully written back, start=%llu len=%llu\n",
+			     found_start, found_end + 1 - found_start);
+			ret = -EUCLEAN;
+			mutex_unlock(&fs_info->tree_log_mutex);
+			goto scrub_continue;
+		}
+		ret = test_range_bit(&BTRFS_I(fs_info->btree_inode)->io_tree, 0,
+				     (u64)-1, EXTENT_DIRTY | EXTENT_WRITEBACK,
+				     0, NULL);
+		if (ret > 0) {
+			WARN(1,
+		"btree io_tree not fully written back, start=%llu len=%llu\n",
+			     found_start, found_end + 1 - found_start);
+			ret = -EUCLEAN;
+			mutex_unlock(&fs_info->tree_log_mutex);
+			goto scrub_continue;
+		}
+	}
+
 	spin_lock(&fs_info->trans_lock);
 	cur_trans->state = TRANS_STATE_UNBLOCKED;
 	fs_info->running_transaction = NULL;
-- 
2.20.1


             reply	other threads:[~2019-02-21  8:23 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-21  8:22 Qu Wenruo [this message]
2019-02-21 14:25 ` [RFC PATCH] btrfs: Introduce developer-oriented check to ensure all tree blocks are written back before writing super blocks Nikolay Borisov
2019-02-21 14:32   ` Qu Wenruo
2019-02-21 15:01     ` Nikolay Borisov
2019-02-26  7:38 ` Qu Wenruo

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=20190221082249.24187-1-wqu@suse.com \
    --to=wqu@suse.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 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).