Sporadic data corruption on a VHD virtual disk with ext4 => fixed in SVN/next maintenance

[Mikhail Kovalev]

We observed this problem on VirtualBox 6.1.18 - 6.1.26, Windows 10 host, Debian 9 or Debian 10 VM. We don't know if the other versions are affected or not. We could reproduce it with and without Hyper-V enabled. So far we only saw this problem on small VHDs (up to 10MB size) with the ext4 file system.

How to reproduce:

1. Start the VM
2. Attach a VHD (~10 MB size) to the (running) VM. We were creating a fresh VHD using the VirtualBox UI here.
3. Format the disk from the VM. We used the following command:

   mkfs.ext4 -m 0 /dev/sdb
   

4. Mount the disk inside the VM. We used the following mounting options:

   mount -t ext4 -o sync,nodelalloc /dev/sdb /test
   

Note: if we remove the "nodelalloc" setting, it's much harder to reproduce the data corruption (but we still could reproduce it a few times).

5. Write some data to the disk. E.g.

   dd bs=1 count=60 if=/dev/random of=/test/test1
   

6. Unmount the disk and mount it again:

   umount/mount
   mount -t ext4 -o sync,nodelalloc /dev/sdb /test
   

7. The data on the disk might get corrupted now: the file content will be replaced with NULL bytes (either the whole file or starting from some offset). Screenshot attached. The corruption doesn't happen every time. But we can easily reproduce it in 2-3 tries at most.

I am also attaching VBox.log and the zipped corrupted .vhd.

[Mikhail Kovalev]

Screenshot of data corruption

[Mikhail Kovalev]

VBox.log

[Mikhail Kovalev]

Corrupted vhd

[Mikhail Kovalev]

The VBox.log is from a custom VirtualBox build. But we can also reproduce the problem on the original VirtualBox. So if this is critical - I can provide a VBox.log from the original VirtualBox

[aeichner]

Thanks for the report, this will be fixed in the next maintenance release! This happens only if the virtual disk size of the image (9. something MiB in your case) is not aligned to the VHD data block size (the default is 2 MiB) and the guest tries to allocate the last block in the image. So the current workaround until a fixed version is released is to make sure that the disk image size is a multiple of 2MiB.

[Klaus Espenlaub]

Attached the diff in case it's urgent. Yes, you're using a very odd size of the disk image in your reproduction case (and likely in the other cases where this happened in production). You end up with a disk image with 19407 sectors or 9,936,384 bytes, i.e. even less than the 19531 or 19532 sectors which would be the "rounded down" or "rounded up" value for a disk size of 10,000,000 bytes (giving 9,999,872 bytes or 10,000,384 bytes).

[Mikhail Kovalev]

Thank you very much, both for the patch and for the explanation!