I am moving from one cloud hosting provider to another
old: FreeBSD geli 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
new: FreeBSD geli 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC amd64
Now I am doing some pretty wild things with geli attached encrypted chunks (my nifty encrypted backup system), but in the end the chunks which are imported by zpool are accessible on both old and new system in the same way, and passing the raw md5 checksum test:
this looks exactly the same on the old and the new system. Each of the chunks is 1 GB. Trying to import that on the new system:
on the old system this is no problem at all. I don't want to do it now because as soon as I import, the data changes and I don't want to keep moving it between the systems.
I moved the raw encrypted chunks with rsync and the -S option. Those too checked out as identical with md5, but they have different sparsity. On the old system it is more crude:
while on the new system rsync -S has punched a hole into every little sequence of zeros, and apparently left some physical zeroes in place, not great I wish there was a way of rsync-in exact copies
but ultimately it doesn't matter if there is a hole or if there are physical zeroes, neither should cause us to get data corruption.
Under what circumstances can completely equivalent binaries come out as "corrupted data" in a newer version of ZFS?
old: FreeBSD geli 11.2-RELEASE-p4 FreeBSD 11.2-RELEASE-p4 #0: Thu Sep 27 08:16:24 UTC 2018 root@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC amd64
new: FreeBSD geli 12.2-RELEASE FreeBSD 12.2-RELEASE r366954 GENERIC amd64
Now I am doing some pretty wild things with geli attached encrypted chunks (my nifty encrypted backup system), but in the end the chunks which are imported by zpool are accessible on both old and new system in the same way, and passing the raw md5 checksum test:
Code:
[root@geli ~/tank]# md5 eli/*
MD5 (eli/000) = 8ce088d5041bfaa341e25924f2251093
MD5 (eli/001) = 3ae3ee8523468ab33e8cf6e4b97ac743
MD5 (eli/002) = a5f1ebd6080e490d1c7fa30c7ede3278
MD5 (eli/003) = 712b0a7bd62a5ab6aae1c84052a54928
MD5 (eli/004) = fe3885c979042035303e0b9cc6e221c6
MD5 (eli/005) = 8fd0ff94923e6bfbf6a02b3497b0f593
MD5 (eli/006) = cdac2ea92d76f4ef0398c5c2b681a23d
MD5 (eli/007) = ae91f162ef6366a7d777750e759fadf6
MD5 (eli/008) = b3f27d57e6f484048af7d7ce8c7b37bd
MD5 (eli/009) = 9ec93a2bbe2bad421c8a712f400d78dc
this looks exactly the same on the old and the new system. Each of the chunks is 1 GB. Trying to import that on the new system:
Code:
[root@geli ~/tank]# zpool import -d eli/
pool: tank
id: 11049249911459966368
state: UNAVAIL
status: One or more devices contains corrupted data.
action: The pool cannot be imported due to damaged devices or data.
see: http://illumos.org/msg/ZFS-8000-5E
config:
tank UNAVAIL insufficient replicas
raidz1-0 UNAVAIL insufficient replicas
5835921389226581455 UNAVAIL corrupted data
2177416200374230478 UNAVAIL corrupted data
11752386467464837990 UNAVAIL corrupted data
6039997508411594910 UNAVAIL corrupted data
18179997039147844315 UNAVAIL corrupted data
4879104888201288613 UNAVAIL corrupted data
7184493838235485359 UNAVAIL corrupted data
9860684163225777268 UNAVAIL corrupted data
808020562372718413 UNAVAIL corrupted data
12039709651413842877 UNAVAIL corrupted data
on the old system this is no problem at all. I don't want to do it now because as soon as I import, the data changes and I don't want to keep moving it between the systems.
I moved the raw encrypted chunks with rsync and the -S option. Those too checked out as identical with md5, but they have different sparsity. On the old system it is more crude:
Code:
[root@geli ~/tank]# ./mapsparse <chunk/000
hole found at 0 379813888 379813888
data found at 379813888 379977728 163840
hole found at 379977728 1024262144 644284416
data found at 1024262144 1069547520 45285376
hole found at 1069547520 1073741824 4194304
while on the new system rsync -S has punched a hole into every little sequence of zeros, and apparently left some physical zeroes in place, not great I wish there was a way of rsync-in exact copies
Code:
[root@geli ~/tank]# ./mapsparse <chunk/000
hole found at 0 524288 524288
data found at 524288 4194304 3670016
hole found at 4194304 5537792 1343488
data found at 5537792 5570560 32768
hole found at 5570560 5603328 32768
data found at 5603328 5636096 32768
hole found at 5636096 6356992 720896
data found at 6356992 6389760 32768
hole found at 6389760 6979584 589824
data found at 6979584 7143424 163840
...
...
but ultimately it doesn't matter if there is a hole or if there are physical zeroes, neither should cause us to get data corruption.
Under what circumstances can completely equivalent binaries come out as "corrupted data" in a newer version of ZFS?