Re: btrfs send picks wrong subvolume UUID

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

otrd., 2022. g. 11. janv., plkst. 17:33 — lietotājs Nikolay Borisov
(<nborisov@suse.com>) rakstīja:
>
>
>
> On 3.01.22 г. 20:09, 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. 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.
>
>
> That behavior got fixed in btrfs-progs in version 5.14, in particular
> commit:
>
> https://github.com/kdave/btrfs-progs/commit/3b90ebc2d7eb4b4a4d5d55eff362e8127a673828
>
> Of course it requires users upgrading btrfs-progs but even if we merged
> some kernel-side fix (there's been one I authored couple of years ago
> and it's been circulated on the mailing list but didn't get merged) it
> would still require users upgrading their kernel eventually.
>

The issue is not that users wouldn't update, but that old filesystems
are already present with this case. This is why fix in btrfs-progs
doesn't help. It prevents it only happening in future but not for
people who already have such filesystems thus kernel fix is necessary
as I described.