Re: btrfs send picks wrong subvolume UUID

["Dāvis Mosāns" <davispuh@gmail.com>]

svētd., 2022. g. 2. janv., plkst. 22:37 — lietotājs Andrei Borzenkov
(<arvidjaar@gmail.com>) rakstīja:
>
> On Sun, Jan 2, 2022 at 8:05 PM Dāvis Mosāns <davispuh@gmail.com> wrote:
> >
> > Hi,
> >
> > I have a bunch of snapshots I want to send from one fs to another,
> > but it seems btrfs send is using received UUID instead of subvolumes own UUID
> > causing wrong subvolume to be picked by btrfs receive and thus failing.
> >
> > $ btrfs subvolume show /mnt/fs/2019-11-02/etc | head -n 5
> > 2019-11-02/etc
> >         Name:                   etc
> >         UUID:                   389ebc5e-341a-fb4a-b838-a2b7976b8220
> >         Parent UUID:            36d5d44b-9eaf-8542-8243-ad0dc45b8abd
> >         Received UUID:          15bd7d35-9f98-0b48-854c-422c445f7403
> >
>
> btrfs send will always use received UUID if available, it works as
> designed and is not a bug. Bug is to have received UUID on read-write
> subvolume. btrfs does not prevent it and it is the result of wrong
> handling on the user side. You should never ever change read-only
> subvolume used for send/receive to read-write directly - instead you
> should always create writable clone from it.
>
> This was discussed extensively, see e.g.
> https://lore.kernel.org/linux-btrfs/d73a72b5-7b53-4ff3-f9b7-1a098868b967@gmail.com/

I consider it as bug. How can anyone know they shouldn't do that. It
is perfectly valid use case for sending subvolumes from one system to
another system. After sending using "btrfs property set ro false" to
set RW. Sounds very logical, why should I create a new snapshot? I
just sent new one. Original system's subvolume could even be deleted
with no plans to ever do any incremental sends. And seems many people
have had this issue which just proves my point it's a bug. And if this
is not supported, then why there exists such "btrfs property set ro
false" at all who lets you shoot yourself in foot? If it didn't exist
then everyone would use only other option by creating new RW snapshot
which actually sounds more like a workaround for broken property set.
So I would say first bug that needs fixing is changing "btrfs property
set ro false" in kernel so that it clears received_uuid and
regenerates new subvolume uuid because such modified subvolume isn't
same as source and would still causes issue if it stayed same.
That would fix it for future but wouldn't solve it for many people who
already have such subvolumes. And it's pretty hard problem to track
down unless you already know it. Like it took me a lot of time to
figure out why send is failing. ro->rw was done 7 years ago and all
snapshots since then have same received_uuid but I noticed btrfs send
not working only now. For me, easiest way I'll just patch kernel to
always use subvolume's uuid and ignore received_uuid, then btrfs send
all snapshots so it will work fine for me. As for others, in general
seems proper fix would be that btrfs send would give both uuid and
received_uuid. Then btrfs receive could have a flag to ignore
received_uuid and just use uuid. Or search by uuid and then fallback
to received_uuid.