From: Nikolay Borisov <nborisov@suse.com>
To: Qu Wenruo <wqu@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 1/2] btrfs-progs: do extra warning when setting ro false on received subvolume
Date: Fri, 10 Sep 2021 09:36:21 +0300 [thread overview]
Message-ID: <e1dbfdc6-d1d8-12d4-cbcf-1dd02c935df4@suse.com> (raw)
In-Reply-To: <20210910060335.38617-2-wqu@suse.com>
On 10.09.21 г. 9:03, Qu Wenruo wrote:
> 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");
This is a bad format for a warning, let's keep it simple - just state
that flipping ro->rw would break incremental send and that's that.
> +}
> +
> 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);
>
next prev parent reply other threads:[~2021-09-10 6:36 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 ` [PATCH 1/2] btrfs-progs: do extra warning when setting ro false on received subvolume Qu Wenruo
2021-09-10 6:36 ` Nikolay Borisov [this message]
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=e1dbfdc6-d1d8-12d4-cbcf-1dd02c935df4@suse.com \
--to=nborisov@suse.com \
--cc=linux-btrfs@vger.kernel.org \
--cc=wqu@suse.com \
/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