Re: btrfs send picks wrong subvolume UUID

[David Sterba <dsterba@suse.cz>]

On Tue, Jan 11, 2022 at 06:46:11PM +0200, Dāvis Mosāns wrote:
> 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.

The progs fix can do (and does) the same as what kernel would do (while
cluttering the ioctl implementation a bit).

Old filesystems, where ro/rw switch has happened on sent subvolumes will
be reported and warn in command 'btrfs subvolume show'. To reset the
received_uuid, flipping the ro/rw property works since 5.14.2, and this
is needed just once on any affected subvolume.

Updating the progs should be easier than updating kernel, so the fix is
there and available also for LTS kernels.