Encrypted disk image with BTRFS filesystem shows checksum errors

Discussions about using Linux guests in VirtualBox.

Encrypted disk image with BTRFS filesystem shows checksum errors

Postby Rob_NRG » 22. Jan 2022, 17:26

I recently transferred a VMware guest with Ubuntu 21.10 (64 bit) with rsync to a new PC to be used with VirtualBox VM 6.1.30 r148432 linux.amd64 (Nov 22 2021 15:58:48) on a Ubuntu 18.04 (64 bit) host system that's using BTRFS just like the guest.

Everything is fine until I encrypt the 30GB VMDK disk image. When I start the guest system and run a filesystem check inside the guest with

Code: Select all   Expand viewCollapse view
btrfs check --check-data-csum --force /dev/sda1

then I get over 249,000 checksum (csum) errors:

Code: Select all   Expand viewCollapse view
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda1
UUID: e3ca8369-7b09-4636-8861-34c7db7c0991
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking csums against data
mirror 1 bytenr 1744568320 csum 61 expected csum 137
mirror 1 bytenr 1744572416 csum 96 expected csum 137
mirror 1 bytenr 1744576512 csum 155 expected csum 137
mirror 1 bytenr 1744580608 csum 115 expected csum 137
mirror 1 bytenr 1744584704 csum 70 expected csum 137
mirror 1 bytenr 1744588800 csum 75 expected csum 137
mirror 1 bytenr 1744592896 csum 8 expected csum 137
mirror 1 bytenr 1744596992 csum 228 expected csum 137
mirror 1 bytenr 1744601088 csum 7 expected csum 137

[lots of similar lines removed]

mirror 1 bytenr 26459619328 csum 207 expected csum 137
mirror 1 bytenr 26459623424 csum 239 expected csum 137
mirror 1 bytenr 26459627520 csum 32 expected csum 137
mirror 1 bytenr 26459631616 csum 37 expected csum 137
ERROR: errors found in csum tree
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
Opening filesystem to check...
Checking filesystem on /dev/sda1
UUID: e3ca8369-7b09-4636-8861-34c7db7c0991
found 20420161536 bytes used, error(s) found
total csum bytes: 18855976
total tree bytes: 354910208
total fs tree bytes: 301727744
total extent tree bytes: 26656768
btree space waste bytes: 68733519
file data blocks allocated: 23902547968
 referenced 19508363264

As you can see in the list of checksum errors, it always expects a checksum of 137. It's never a different value. I even repeated the encryption and decryption several times. The result stays the same. The encrypted disk image shows BTRFS checksum errors, the unencrypted disk image is free of errors, as shown here:

Code: Select all   Expand viewCollapse view
Opening filesystem to check...
WARNING: filesystem mounted, continuing because of --force
Checking filesystem on /dev/sda1
UUID: e3ca8369-7b09-4636-8861-34c7db7c0991
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space cache
[4/7] checking fs roots
[5/7] checking csums against data
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 20505137152 bytes used, no error found
total csum bytes: 18927052
total tree bytes: 371589120
total fs tree bytes: 319340544
total extent tree bytes: 26263552
btree space waste bytes: 70951007
file data blocks allocated: 21667954688
 referenced 19611136000

This is the base VMDK file describing the disk image which consists of 8 files:

Code: Select all   Expand viewCollapse view
# Disk DescriptorFile
version=1
encoding="UTF-8"
CID=90e52165
parentCID=ffffffff
createType="twoGbMaxExtentSparse"

# Extent description
RW 8323072 SPARSE "Virtuelle Festplatte-s001.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s002.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s003.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s004.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s005.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s006.vmdk"
RW 8323072 SPARSE "Virtuelle Festplatte-s007.vmdk"
RW 4653056 SPARSE "Virtuelle Festplatte-s008.vmdk"

# The Disk Data Base
#DDB

ddb.adapterType = "lsilogic"
ddb.deletable = "true"
ddb.geometry.cylinders = "16383"
ddb.geometry.heads = "16"
ddb.geometry.sectors = "63"
ddb.longContentID = "4d0ac0679f3be8b1e488b2ee90e52165"
ddb.toolsInstallType = "4"
ddb.toolsVersion = "11360"
ddb.uuid = "60 00 C2 9f c1 40 d9 9e-71 b3 90 15 ae 06 77 6c"
ddb.virtualHWVersion = "4"
ddb.uuid.image="fd399ba7-3184-4ec2-a43c-ba39435d7502"
ddb.uuid.modification="92bcbff8-4b51-491f-a10c-d7e524969963"
ddb.uuid.parent="00000000-0000-0000-0000-000000000000"
ddb.uuid.parentmodification="00000000-0000-0000-0000-000000000000"
ddb.geometry.biosCylinders="1024"
ddb.geometry.biosHeads="255"
ddb.geometry.biosSectors="63"

I've the feeling it has something to do with the sparse disk image and sectors that are supposed to contain only 4096 zero bytes, thus creating the same checksum 137. After encrypting the disk image, these sectors might no longer contain only zeroes when read by the virtual guest and therefore the checksum is different. But it could be also something completely different that totally relies on the encryption status of the disk image.

Robert
Attachments
VBox.log.zip
VBox.log of the guest with encrypted disk image
(38.33 KiB) Downloaded 1 time
Rob_NRG
 
Posts: 1
Joined: 22. Jan 2022, 16:12

Return to Linux Guests

Who is online

Users browsing this forum: No registered users and 18 guests