public inbox for linux-btrfs@vger.kernel.org
 help / color / mirror / Atom feed
From: Qu Wenruo <wqu@suse.com>
To: linux-btrfs@vger.kernel.org
Subject: [PATCH 1/2] btrfs-progs: do extra warning when setting ro false on received subvolume
Date: Fri, 10 Sep 2021 14:03:34 +0800	[thread overview]
Message-ID: <20210910060335.38617-2-wqu@suse.com> (raw)
In-Reply-To: <20210910060335.38617-1-wqu@suse.com>

When flipping received subvolume from RO to RW, any new write to the
subvolume could cause later incremental receive to fail or corrupt data.

Thus we're trying to clear received UUID when doing such RO->RW flip, to
prevent data corruption.

But unfortunately the old (and wrong) behavior has been there for a
while, and changing the kernel behavior will make existing users
confused.

Thus here we enhance subvolume read-only prop to do extra warning on
users to educate them about both the new behavior and the problems of
old behaviors.

Signed-off-by: Qu Wenruo <wqu@suse.com>
---
 props.c | 21 +++++++++++++++++++++
 1 file changed, 21 insertions(+)

diff --git a/props.c b/props.c
index 81509e48cd16..b86ecc61b5b3 100644
--- a/props.c
+++ b/props.c
@@ -39,6 +39,15 @@
 #define ENOATTR ENODATA
 #endif
 
+static void do_warn_about_rorw_flip(const char *path)
+{
+	warning("Flipping subvolume %s from RO to RW will cause either:", path);
+	warning("- No more incremental receive based on this subvolume");
+	warning("  Newer kernels will remove the recevied UUID to prevent corruption");
+	warning("- Data corruption or receive corruption doing incremental receive");
+	warning("  Older kernels can't detect the modification, and cause corruption or receive failure");
+}
+
 static int prop_read_only(enum prop_object_type type,
 			  const char *object,
 			  const char *name,
@@ -48,6 +57,9 @@ static int prop_read_only(enum prop_object_type type,
 	bool read_only;
 
 	if (value) {
+		struct btrfs_util_subvolume_info subvol;
+		u8 empty_uuid[BTRFS_UUID_SIZE] = { 0 };
+
 		if (!strcmp(value, "true")) {
 			read_only = true;
 		} else if (!strcmp(value, "false")) {
@@ -57,6 +69,15 @@ static int prop_read_only(enum prop_object_type type,
 			return -EINVAL;
 		}
 
+		err = btrfs_util_subvolume_info(object, 0, &subvol);
+		if (err) {
+			warning("unable to get subvolume info for path %s",
+				object);
+		} else if (!read_only && memcmp(empty_uuid, subvol.received_uuid,
+				   BTRFS_UUID_SIZE)){
+			do_warn_about_rorw_flip(object);
+		}
+
 		err = btrfs_util_set_subvolume_read_only(object, read_only);
 		if (err) {
 			error_btrfs_util(err);
-- 
2.33.0


  reply	other threads:[~2021-09-10  6:03 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-09-10  6:03 [PATCH 0/2] btrfs-progs: add educational warning for flipping RO to RW on recevied subvolumes Qu Wenruo
2021-09-10  6:03 ` Qu Wenruo [this message]
2021-09-10  6:36   ` [PATCH 1/2] btrfs-progs: do extra warning when setting ro false on received subvolume Nikolay Borisov
2021-09-10  7:28     ` Qu Wenruo
2021-09-10  9:38       ` Graham Cobb
2021-09-10  6:03 ` [PATCH 2/2] btrfs-progs: doc: add extra note on flipping read-only on received subvolumes Qu Wenruo
2021-09-10  6:33   ` Nikolay Borisov
2021-09-10  7:30     ` Qu Wenruo
2021-09-10  9:48       ` Graham Cobb
2021-09-10  9:45     ` David Sterba
2021-09-10  9:59       ` Qu Wenruo
2021-09-10 10:50         ` 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=20210910060335.38617-2-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