Clonage is unsetting the received UUID

[Morikko]

The setup:

1. A FS at bk1 with a subvol chains where a few ro snapshots in it.
2. Another FS at bk2 empty

./btrfs-clone --toplevel --verbose bk1 bk2

Expected: The snapshots in bk1/chains/* are send | receive so the received UUID must be set for each one.

Actual:

btrfs su list -qRo bk2/c3bffbc5bc4d/chains/
# ID 263 gen 25 top level 266 parent_uuid -                                    received_uuid -                                    path c3bffbc5bc4d/chains/chain-1
# ID 264 gen 29 top level 266 parent_uuid -                                    received_uuid -                                    path c3bffbc5bc4d/chains/chain-4
# ID 265 gen 30 top level 266 parent_uuid 48298098-567e-ca4a-a682-2b60ba328e1c received_uuid -                                    path c3bffbc5bc4d/chains/toto-snap

Logs

unsharing mount namespace
OLD btrfs 3279dff0-86b2-4ffb-aa9c-7b69433f889b mounted on /tmp/tmpy6u3euif
NEW btrfs 58cdcc9f-7b1f-41be-8bcf-375d39b0cec1 mounted on /tmp/tmpesva_93o
Create a readonly snapshot of '/tmp/tmpy6u3euif' in '/tmp/tmpy6u3euif/c3bffbc5bc4d'
btrfs send -v /tmp/tmpy6u3euif/c3bffbc5bc4d |
         btrfs receive -v /tmp/tmpesva_93o
btrfs property set -f /tmp/tmpesva_93o/c3bffbc5bc4d ro false
top level subvol in clone is: c3bffbc5bc4d
Using cloning strategy GenerationStrategy
btrfs property set -ts /tmp/tmpy6u3euif/chains ro true
chains/chain-1(257) <= None (reason: orphan); 
btrfs send -v /tmp/tmpy6u3euif/chains/chain-1 |
         btrfs receive -v /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/257
chains/chain-4(259) <= None (reason: orphan); 
btrfs send -v /tmp/tmpy6u3euif/chains/chain-4 |
         btrfs receive -v /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/259
chains/toto-snap(260) <= chains/chain-4(259) (reason: mom); chains/chain-4(259)
btrfs send -v -c /tmp/tmpy6u3euif/chains/chain-4 -p /tmp/tmpy6u3euif/chains/chain-4 /tmp/tmpy6u3euif/chains/toto-snap |
         btrfs receive -v /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/260
At snapshot toto-snap
chains(256) <= None (reason: orphan); 
btrfs send -v /tmp/tmpy6u3euif/chains |
         btrfs receive -v /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/256
btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/256/chains ro false
c3bffbc5bc4d(261) <= None (reason: orphan); 
btrfs send -v /tmp/tmpy6u3euif/c3bffbc5bc4d |
         btrfs receive -v /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/261
mv -f /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/256/chains /tmp/tmpesva_93o/c3bffbc5bc4d
btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/261/c3bffbc5bc4d ro false
mv -f /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/261/c3bffbc5bc4d /tmp/tmpesva_93o/c3bffbc5bc4d
btrfs property set -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c3bffbc5bc4d ro true
btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/257/chain-1 ro false
mv -f /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/257/chain-1 /tmp/tmpesva_93o/c3bffbc5bc4d/chains
btrfs property set -ts /tmp/tmpesva_93o/c3bffbc5bc4d/chains/chain-1 ro true
btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/259/chain-4 ro false
mv -f /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/259/chain-4 /tmp/tmpesva_93o/c3bffbc5bc4d/chains
btrfs property set -ts /tmp/tmpesva_93o/c3bffbc5bc4d/chains/chain-4 ro true
btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/260/toto-snap ro false
mv -f /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/260/toto-snap /tmp/tmpesva_93o/c3bffbc5bc4d/chains
btrfs property set -ts /tmp/tmpesva_93o/c3bffbc5bc4d/chains/toto-snap ro true
btrfs property set -f -ts /tmp/tmpy6u3euif/chains ro false
Delete subvolume 261 (no-commit): '/tmp/tmpy6u3euif/c3bffbc5bc4d'

The reason is probably : btrfs property set -f -ts /tmp/tmpesva_93o/c3bffbc5bc4d/c393996ce277/261/c3bffbc5bc4d ro false. It is the root cause of #19 and by passing -f the received UUID is reset.

Not sure why a ro snapshot must be changed to rw. The only log in between is a move but normally a mv should not be problematic as long as targeting the snapshot root folder.

[mwilck]

Not sure why a ro snapshot must be changed to rw

We have a problem here.

btrfs-clone is 7 years old. I've uploaded it here in the hope that it would be useful. I personally haven't used it for years, and I have no time for exhaustive maintenance.

As turned out in #19, there have been changes in the kernel and btrfsprogs that affect the functionality of btrfs-clone to the extent that it doesn't work any more for certain setups. Apparently the fact that I merged #21 has caused breakage in your case. That's regrettable, and exactly the reason why I am reluctant to merge changes like this.

I don't remember why it was necessary to clear the ro property in the code path you mention. But I am pretty sure that I found it necessary back then, otherwise I wouldn't have invested the effort to write the code that does it. It's well possible that back in 2017 it was necessary (talking about kernel 4.x), while it isn't any more today.

Feel free to comment out or remove the set_ro call in the code in question, see if it works better, and let me know.

[Morikko]

btrfs-clone is 7 years old. I've uploaded it here in the hope that it would be useful. I personally haven't used it for years, and I have no time for exhaustive maintenance.

I understand, thank you for the initial work and the answer. At least, I wanted to highlight the issue to let other people know. As this tool is still part of many answers on how to clone a btrfs disk. It is maybe not perfect but it may still help for some cases.

On my side, I wanted to migrate a disk with only btrbk snapshots. I used this tool first as I thought that btrbk needed some custom configuration and to do each backup group separately. At the end, I did use btrbk archive /mnt/source /mnt/target as it worked recursively. It even ended being better in term of COW optimization as btrbk use a timestamp on the snapshot name to order the sequence.

As a result, I won't change this tool as I will stick with btrbk.