Re: btrfs send picks wrong subvolume UUID

[Nikolay Borisov <nborisov@suse.com>]

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.

>