* btrfs send picks wrong subvolume UUID @ 2022-01-02 4:17 Dāvis Mosāns 2022-01-02 20:37 ` Andrei Borzenkov 0 siblings, 1 reply; 7+ messages in thread From: Dāvis Mosāns @ 2022-01-02 4:17 UTC (permalink / raw) To: Btrfs 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 /mnt/fs/2019-11-02/etc | btrfs receive --dump | head -n 2 At subvol /mnt/fs/2019-11-02/etc subvol ./etc uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=1727996 chown ./etc/ gid=0 uid=0 $ btrfs send /mnt/fs/2019-11-02/etc | btrfs receive /mnt/newFS/2019-11-02/ At subvol /mnt/fs/2019-11-02/etc At subvol etc $ btrfs subvolume show /mnt/fs/2020-09-21/etc | head -n 5 2020-09-21/etc Name: etc UUID: 1c6a0138-b23b-244f-82d8-e2fcaa20870f Parent UUID: 36d5d44b-9eaf-8542-8243-ad0dc45b8abd Received UUID: 15bd7d35-9f98-0b48-854c-422c445f7403 $ btrfs send -c /mnt/fs/2019-11-02/etc -p /mnt/fs/2019-11-02/etc /mnt/fs/2020-09-21/etc | btrfs receive --dump | head -n 2 At subvol /mnt/fs/2020-09-21/etc snapshot ./etc uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=2148016 parent_uuid=15bd7d35-9f98-0b48-854c-422c445f7403 parent_transid=1727996 utimes ./etc/ atime=2019-08-11T14:56:46+0300 mtime=2020-09-21T20:30:38+0300 ctime=2020-09-21T20:30:38+0300 $ btrfs send -c /mnt/fs/2019-11-02/etc -p /mnt/fs/2019-11-02/etc /mnt/fs/2020-09-21/etc | btrfs receive /mnt/newFS/2020-09-21/ At subvol /mnt/fs/2020-09-21/etc At snapshot etc $ btrfs subvolume list -opuqR /mnt/newFS/ ID 373 gen 1965 parent 276 top level 276 parent_uuid - received_uuid 15bd7d35-9f98-0b48-854c-422c445f7403 uuid 4a21e16f-ab4e-1f45-900a-541ead4e9fa4 path 2019-11-02/etc ID 374 gen 1968 parent 276 top level 276 parent_uuid 4a21e16f-ab4e-1f45-900a-541ead4e9fa4 received_uuid 15bd7d35-9f98-0b48-854c-422c445f7403 uuid 7e19706d-4cf4-8245-ae02-1bdd99f92e48 path 2020-09-21/etc As you can see received_uuid is same for both and it's not the UUID of source subvolume $ btrfs subvolume show /mnt/fs/2020-12-09/etc | head -n 5 2020-12-09/etc Name: etc UUID: 2902708e-2ebf-654a-8b03-f854e031f8c7 Parent UUID: 36d5d44b-9eaf-8542-8243-ad0dc45b8abd Received UUID: 15bd7d35-9f98-0b48-854c-422c445f7403 $ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc /mnt/fs/2020-12-09/etc | btrfs receive --dump | head -n 2 At subvol /mnt/fs/2020-12-09/etc snapshot ./etc uuid=15bd7d35-9f98-0b48-854c-422c445f7403 transid=2212940 parent_uuid=15bd7d35-9f98-0b48-854c-422c445f7403 parent_transid=2148016 utimes ./etc/ atime=2019-08-11T14:56:46+0300 mtime=2020-12-08T17:50:18+0200 ctime=2020-12-08T17:50:18+0200 $ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc /mnt/fs/2020-12-09/etc | btrfs receive /mnt/newFS/2020-12-09/ At subvol /mnt/fs/2020-12-09/etc At snapshot etc ERROR: unlink o86334-1390558-0/d42ee4920c54898f1957cd2f38799f735dfa05 failed: No such file or directory Here it fails because it actually used target's 2019-11-02/etc subvolume as parent instead of 2020-09-21/etc like we specified. We can see that in strace: $ btrfs send -c /mnt/fs/2020-09-21/etc -p /mnt/fs/2020-09-21/etc /mnt/fs/2020-12-09/etc | strace btrfs receive /mnt/newFS/2020-12-09/ 2>&1 | grep -E '2019-11-02|SNAP_CREATE' At subvol /mnt/fs/2020-12-09/etc ioctl(4, BTRFS_IOC_INO_LOOKUP, {treeid=276, objectid=261} => {name="2019-11-02/"}) = 0 openat(4, "2019-11-02/etc", O_RDONLY|O_NOATIME) = 5 ioctl(3, BTRFS_IOC_SNAP_CREATE_V2, {fd=5, flags=0, name="etc"} => {transid=0}) = 0 Best regards, Dāvis ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-02 4:17 btrfs send picks wrong subvolume UUID Dāvis Mosāns @ 2022-01-02 20:37 ` Andrei Borzenkov 2022-01-03 18:09 ` Dāvis Mosāns 0 siblings, 1 reply; 7+ messages in thread From: Andrei Borzenkov @ 2022-01-02 20:37 UTC (permalink / raw) To: Dāvis Mosāns; +Cc: Btrfs 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/ ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-02 20:37 ` Andrei Borzenkov @ 2022-01-03 18:09 ` Dāvis Mosāns 2022-01-11 15:33 ` Nikolay Borisov 2022-01-12 11:37 ` David Sterba 0 siblings, 2 replies; 7+ messages in thread From: Dāvis Mosāns @ 2022-01-03 18:09 UTC (permalink / raw) To: Andrei Borzenkov; +Cc: Btrfs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-03 18:09 ` Dāvis Mosāns @ 2022-01-11 15:33 ` Nikolay Borisov 2022-01-11 16:46 ` Dāvis Mosāns 2022-01-12 11:37 ` David Sterba 1 sibling, 1 reply; 7+ messages in thread From: Nikolay Borisov @ 2022-01-11 15:33 UTC (permalink / raw) To: Dāvis Mosāns, Andrei Borzenkov; +Cc: Btrfs 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. > ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-11 15:33 ` Nikolay Borisov @ 2022-01-11 16:46 ` Dāvis Mosāns 2022-01-12 11:29 ` David Sterba 0 siblings, 1 reply; 7+ messages in thread From: Dāvis Mosāns @ 2022-01-11 16:46 UTC (permalink / raw) To: Nikolay Borisov; +Cc: Andrei Borzenkov, Btrfs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-11 16:46 ` Dāvis Mosāns @ 2022-01-12 11:29 ` David Sterba 0 siblings, 0 replies; 7+ messages in thread From: David Sterba @ 2022-01-12 11:29 UTC (permalink / raw) To: Dāvis Mosāns; +Cc: Nikolay Borisov, Andrei Borzenkov, Btrfs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: btrfs send picks wrong subvolume UUID 2022-01-03 18:09 ` Dāvis Mosāns 2022-01-11 15:33 ` Nikolay Borisov @ 2022-01-12 11:37 ` David Sterba 1 sibling, 0 replies; 7+ messages in thread From: David Sterba @ 2022-01-12 11:37 UTC (permalink / raw) To: Dāvis Mosāns; +Cc: Andrei Borzenkov, Btrfs 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. ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2022-01-12 11:37 UTC | newest] Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2022-01-02 4:17 btrfs send picks wrong subvolume UUID Dāvis Mosāns 2022-01-02 20:37 ` Andrei Borzenkov 2022-01-03 18:09 ` Dāvis Mosāns 2022-01-11 15:33 ` Nikolay Borisov 2022-01-11 16:46 ` Dāvis Mosāns 2022-01-12 11:29 ` David Sterba 2022-01-12 11:37 ` David Sterba
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).