On 10/19/2013 06:17, Wang Shilong wrote:
From: Wang Shilong <wangsl.f...@cn.fujitsu.com>Scrubing supers is not in a transaction context, when trying to write supers to disk, we should check if we are trying to scrub supers.Fix it. Signed-off-by: Wang Shilong <wangsl.f...@cn.fujitsu.com> --- fs/btrfs/disk-io.c | 2 ++ fs/btrfs/transaction.c | 2 ++ 2 files changed, 4 insertions(+) diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c index 419968e..0debb19 100644 --- a/fs/btrfs/disk-io.c +++ b/fs/btrfs/disk-io.c @@ -3582,7 +3582,9 @@ int btrfs_commit_super(struct btrfs_root *root) return ret; } + btrfs_scrub_pause_super(root); ret = write_ctree_super(NULL, root, 0); + btrfs_scrub_continue_super(root); return ret; } diff --git a/fs/btrfs/transaction.c b/fs/btrfs/transaction.c index 277fe81..3ebcbbd 100644 --- a/fs/btrfs/transaction.c +++ b/fs/btrfs/transaction.c @@ -1892,7 +1892,9 @@ int btrfs_commit_transaction(struct btrfs_trans_handle *trans, goto cleanup_transaction; } + btrfs_scrub_pause_super(root); ret = write_ctree_super(trans, root, 0); + btrfs_scrub_continue_super(root); if (ret) { mutex_unlock(&root->fs_info->tree_log_mutex); goto cleanup_transaction;
What kind of race do you see between writing the 4K superblock and scrub checking its checksum? Or in other words, what could happen?
-- To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
