Re: btrfs send picks wrong subvolume UUID

[David Sterba <dsterba@suse.cz>]

On Mon, Jan 03, 2022 at 08:09:01PM +0200, Dāvis Mosāns wrote:
> 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.

It may sound logical but breaks assumptions of send, so yes it is a bug
and the fix took more time than convenient, because just fixing the
kernel was not enough and later I realized that's the wrong place to fix
it. There's also updated documentation regarding the usecase so this
should address the "how can anyone know not to do it".

> So I would say first bug that needs fixing is changing "btrfs property
> set ro false" in kernel

So technically it gets cleared in kernel, using the
BTRFS_IOC_SET_RECEIVED_SUBVOL ioctl, but it's initiated by the command
'btrfs prop set ro false' for the subvolume. Effectively there's no
difference for you as a user.