π
2018-03-09 01:01
in Btrfs, Linux
I had a problem when migrating disks and moving read only btrfs receive snapshots. I did a
btrfs snapshot dir1/Video_ro.20180220_21:03:41 dir2/Video_ro.20180220_21:03:41which in turn broke the snapshot by making it read-write and losing the btrfs receive relationship (Received UUID) Later, I wanted to re-establish the btrfs send/receive relationship since it was an 8TB subvolume, and I wanted to avoid having to copy back all the data I already had there. Simply making the destination snapshot read only again did not work The solution was python-btrfs, and this code: https://github.com/knorrie/python-btrfs/commit/1ace623f95300ecf581b1182780fd6432a46b24d
gargamel:python-btrfs/examples# ./set_received_uuid.py 2afc7a5e-107f-d54b-8929-197b80b70828 31337 1234.5678 /mnt/btrfs_bigbackup/DS1/Video_ro.20180220_21:03:411G Current subvolume information: subvol_id: 94887 received_uuid: 00000000-0000-0000-0000-000000000000 stime: 0.0 (1970-01-01T00:00:00) stransid: 0 rtime: 0.0 (1970-01-01T00:00:00) rtransid: 0 Setting received subvolume... Resulting subvolume information: subvol_id: 94887 received_uuid: 2afc7a5e-107f-d54b-8929-197b80b70828 stime: 1234.5678 (1970-01-01T00:20:34.567800) stransid: 31337 rtime: 1520488877.415709329 (2018-03-08T06:01:17.415709) rtransid: 255755 Then make it read-only again: gargamel:python-btrfs/examples# btrfs property set -ts /mnt/btrfs_bigbackup/DS1/Video_ro.20180220_21:03:41 ro true But this didn't work: ABORT: btrfs send -p /mnt/btrfs_pool1/Video_ro.20180220_21:03:41 Video_ro.20180308_07:50:06 | btrfs receive /mnt/btrfs_bigbackup/DS1//. failed At subvol Video_ro.20180308_07:50:06 At snapshot Video_ro.20180308_07:50:06 ERROR: cannot find parent subvolumeYou can see that with set_received_uuid.py, I set Received UUID to match UUID on the source:
gargamel:/mnt/btrfs_pool1# btrfs subvolume show /mnt/btrfs_bigbackup/DS1/Video_ro.20180220_21:03:41 DS1/Video_ro.20180220_21:03:41
Name: Video_ro.20180220_21:03:41
UUID: cb4f343c-5e79-7f49-adf0-7ce0b29f23b3
Parent UUID: 0e220a4f-6426-4745-8399-0da0084f8b23
Received UUID: 2afc7a5e-107f-d54b-8929-197b80b70828 << changed this
Creation time: 2018-02-20 21:13:36 -0800
Subvolume ID: 94887
Generation: 250689
Gen at creation: 250689
Parent ID: 89160
Top level ID: 89160
Flags: readonly
Snapshot(s):
Name: Video_ro.20180220_21:03:41
UUID: 2afc7a5e-107f-d54b-8929-197b80b70828
Parent UUID: e5ec5c1e-6b49-084e-8820-5a8cfaa1b089
Received UUID: 0e220a4f-6426-4745-8399-0da0084f8b23
Creation time: 2018-02-20 21:03:42 -0800
Subvolume ID: 11228
Generation: 4174
Gen at creation: 4150
Parent ID: 5
Top level ID: 5
Flags: readonly
Turns out however that because the source had a Parent UUID value too, I was actually supposed to set Received UUID on the destination to it:
gargamel:python-btrfs/examples# ./set_received_uuid.py 0e220a4f-6426-4745-8399-0da0084f8b23 313 37 1234.5678 /mnt/btrfs_bigbackup/DS1/Video_ro.20180220_21:03:41 Current subvolume information: subvol_id: 94887 received_uuid: 2afc7a5e-107f-d54b-8929-197b80b70828 stime: 1234.5678 (1970-01-01T00:20:34.567800) stransid: 31337 rtime: 1520488877.415709329 (2018-03-08T06:01:17.415709) rtransid: 255755 Setting received subvolume... Resulting subvolume information: subvol_id: 94887 received_uuid: 0e220a4f-6426-4745-8399-0da0084f8b23 stime: 1234.5678 (1970-01-01T00:20:34.567800) stransid: 31337 rtime: 1520537034.890253770 (2018-03-08T19:23:54.890254) rtransid: 256119 gargamel:python-btrfs/examples# btrfs property set -ts /mnt/btrfs_bigbackup/DS1/Video_ro.201802 20_21:03:41 ro trueAfter this, I was able to re-start my btrfs send/receive and /mnt/btrfs_bigbackup/DS1/Video_ro.201802 20_21:03:41 was properly accepted as a destination. Yeah!