linux-btrfs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Anand Jain <anand.jain@oracle.com>
To: dsterba@suse.cz
Cc: linux-btrfs@vger.kernel.org
Subject: Re: [PATCH 11/11] btrfs-progs: tune: fix incomplete fsid_change
Date: Tue, 18 Jul 2023 03:25:24 +0800	[thread overview]
Message-ID: <f561f253-ebe3-0907-bf03-4daa334d3693@oracle.com> (raw)
In-Reply-To: <20230713185726.GE30916@twin.jikos.cz>



On 14/07/2023 02:57, David Sterba wrote:
> On Fri, Jul 07, 2023 at 11:52:41PM +0800, Anand Jain wrote:
>> An incomplete fsid state occurs when devices have two or more fsids
>> associated with the same metadata_uuid. As it can be confusing to
>> determine which devices should be assembled together, the fix only
>> works when both the --noscan and --device options are used. This means
>> the user will have to manually select and assemble the devices with the
>> same metadata_uuids.
> 
> This is not a good usability. If the user can determine which devices
> should be in the --noscan and --device options why can't we do that
> programaticaly?

Technically, there can be many fsids with the same metadata_uuid.
I'm afraid that in all split-brain scenarios, we may not be able
to successfully identify device partners, and assembling the
filesystem with the wrong device could be disastrous.

> If the found devices can be reliably identified as part
> of the filesystem (and there are e.g. no ambiguities due to duplicated
> devices) then the command should work it out by itself.

I expect btrfstune -m to be used more for modifying btrfs file images
rather than block devices. Users can simply copy the image and change
the fsid, which the system won't be aware of unless the user informs
us.

> The btrfstune commands are supposed to be restartable, namely the uuid
> conversions, basically with the same command that was used to begin the
> conversion. If there's a problem that needs user interactions then there
> should be specific instructions what to check and how to resolve it
> manually.

I was trying to avoid yet another cmd option. If the command is
restarted and the superblock has the CHANGING_FSID flag set, then
the command will fail. In this state, we can add specific
instructions on how to continue (i.e., --noscan and --device options
are mandatory). Or any suggestion?

Thanks.

  reply	other threads:[~2023-07-17 19:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-07-07 15:52 [PATCH 00/11] btrfs-progs: fix bugs and CHANGING_FSID_V2 flag Anand Jain
2023-07-07 15:52 ` [PATCH 01/11] btrfs-progs: fix duplicate missing device Anand Jain
2023-07-07 15:52 ` [PATCH 02/11] btrfs-progs: call warn() for " Anand Jain
2023-07-13 18:48   ` David Sterba
2023-07-17 18:22     ` Anand Jain
2023-07-19 14:34       ` Anand Jain
2023-07-07 15:52 ` [PATCH 03/11] btrfs-progs: track missing device counter Anand Jain
2023-07-07 15:52 ` [PATCH 04/11] btrfs-progs: NULL initialize device name for missing Anand Jain
2023-07-07 15:52 ` [PATCH 05/11] btrfs-progs: tune: check for missing device Anand Jain
2023-07-13 18:49   ` David Sterba
2023-07-17 19:02     ` Anand Jain
2023-07-07 15:52 ` [PATCH 06/11] btrfs-progs: track changing_fsid flag in fs_devices Anand Jain
2023-07-07 15:52 ` [PATCH 07/11] btrfs-progs: track num_devices per fs_devices Anand Jain
2023-07-07 15:52 ` [PATCH 08/11] btrfs-progs: track total_devs in fs devices Anand Jain
2023-07-13 18:58   ` David Sterba
2023-07-17 19:28     ` Anand Jain
2023-07-07 15:52 ` [PATCH 09/11] btrfs-progs: track active metadata_uuid per fs_devices Anand Jain
2023-07-07 15:52 ` [PATCH 10/11] btrfs-progs: add helper to reunite devices with same metadata_uuid Anand Jain
2023-07-07 15:52 ` [PATCH 11/11] btrfs-progs: tune: fix incomplete fsid_change Anand Jain
2023-07-13 18:57   ` David Sterba
2023-07-17 19:25     ` Anand Jain [this message]
2023-07-20 14:33       ` Anand Jain

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=f561f253-ebe3-0907-bf03-4daa334d3693@oracle.com \
    --to=anand.jain@oracle.com \
    --cc=dsterba@suse.cz \
    --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).