π
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:41
which 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 subvolume
You 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 true
After 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! |