linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Nikolay Borisov <nborisov@suse.com>
To: linux-btrfs@vger.kernel.org
Cc: Nikolay Borisov <nborisov@suse.com>
Subject: [PATCH 3/6] btrfs: Add handling for disk split-brain scenario during fsid change
Date: Thu, 11 Oct 2018 18:03:23 +0300	[thread overview]
Message-ID: <1539270206-27005-4-git-send-email-nborisov@suse.com> (raw)
In-Reply-To: <1539270206-27005-1-git-send-email-nborisov@suse.com>

Even though FSID change without rewrite is a very quick operations it's
still possible to experience a split brain scenario if power loss
occurs at the right time. This patch handle the case where power
failure occurs while the first transaction (the one setting
FSID_CHANGING_V2) flag is being persisted on disk. This can cause
the btrfs_fs_device of this filesystem to be created by a device which:

 a) has the FSID_CHANGING_V2 flag set but its fsid value is intact

 b) or a device which doesn't have FSID_CHANGING_V2 flag set and its
 fsid value is intact

This situatian is trivially handled by the current find_fsid code since
in both cases the devices are going to be tread like ordinary devices.
Since btrfs is mounted always using the superblock of the latest
device (the one with higher generation number), meaning it will have
the FSID_CHANGING_V2 flag set, ensure it's being cleared. On the first
transaction commit following the mount all disks will have it cleared.

Signed-off-by: Nikolay Borisov <nborisov@suse.com>
---
 fs/btrfs/disk-io.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/fs/btrfs/disk-io.c b/fs/btrfs/disk-io.c
index be2caf513e2f..9c2f46f8421a 100644
--- a/fs/btrfs/disk-io.c
+++ b/fs/btrfs/disk-io.c
@@ -2831,10 +2831,10 @@ int open_ctree(struct super_block *sb,
 	 * the whole block of INFO_SIZE
 	 */
 	memcpy(fs_info->super_copy, bh->b_data, sizeof(*fs_info->super_copy));
-	memcpy(fs_info->super_for_commit, fs_info->super_copy,
-	       sizeof(*fs_info->super_for_commit));
 	brelse(bh);
 
+	disk_super = fs_info->super_copy;
+
 	ASSERT(!memcmp(fs_info->fs_devices->fsid, fs_info->super_copy->fsid,
 		       BTRFS_FSID_SIZE));
 
@@ -2844,6 +2844,15 @@ int open_ctree(struct super_block *sb,
 				BTRFS_FSID_SIZE));
 	}
 
+	features = btrfs_super_flags(disk_super);
+	if (features & BTRFS_SUPER_FLAG_CHANGING_FSID_v2) {
+		features &= ~BTRFS_SUPER_FLAG_CHANGING_FSID_v2;
+		btrfs_set_super_flags(disk_super, features);
+		btrfs_info(fs_info, "Found metadata uuid in progress flag. Clearing\n");
+	}
+
+	memcpy(fs_info->super_for_commit, fs_info->super_copy,
+	       sizeof(*fs_info->super_for_commit));
 
 	ret = btrfs_validate_mount_super(fs_info);
 	if (ret) {
@@ -2852,7 +2861,6 @@ int open_ctree(struct super_block *sb,
 		goto fail_alloc;
 	}
 
-	disk_super = fs_info->super_copy;
 	if (!btrfs_super_root(disk_super))
 		goto fail_alloc;
 
-- 
2.7.4


  parent reply	other threads:[~2018-10-11 15:03 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-11 15:03 [PATCH 0/6] FSID change kernel support Nikolay Borisov
2018-10-11 15:03 ` [PATCH 1/6] btrfs: Introduce support for FSID change without metadata rewrite Nikolay Borisov
2018-10-11 15:03 ` [PATCH 2/6] btrfs: Remove fsid/metadata_fsid fields from btrfs_info Nikolay Borisov
2018-10-11 15:03 ` Nikolay Borisov [this message]
2018-10-11 15:03 ` [PATCH 4/6] btrfs: Introduce 2 more members to struct btrfs_fs_devices Nikolay Borisov
2018-10-11 15:03 ` [PATCH 5/6] btrfs: Handle one more split-brain scenario during fsid change Nikolay Borisov
2018-10-11 15:03 ` [PATCH 6/6] btrfs: Handle final split-brain possibility " Nikolay Borisov
2018-10-19 14:18 ` [PATCH 0/6] FSID change kernel support David Sterba
2018-10-19 14:31   ` Nikolay Borisov
2018-10-19 15:50     ` David Sterba
  -- strict thread matches above, loose matches on Subject: below --
2018-10-30 14:43 [PATCH v3 " Nikolay Borisov
2018-10-30 14:43 ` [PATCH 3/6] btrfs: Add handling for disk split-brain scenario during fsid change Nikolay Borisov

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=1539270206-27005-4-git-send-email-nborisov@suse.com \
    --to=nborisov@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).