Image filesystem corruption with 3.2.0 on Linux amd64 host

[spinkham]

I'm noticing lots of filesystem errors with 3.2.0. It took me 3 tries until the Ubuntu installer would work correctly on a new VM with default settings and the Ubuntu 10.04 x86 desktop ISO.
Once I have it installed, installing updated would randomly fail with messages about truncated files, or on reboot a fsck would find tons of filesystem errors.

Switching back to 3.1.8 has solved all these problems.

The host OS is Ubuntu 10.04 amd64, the guest OS is Ubuntu 10.04 x86, and these problems occur before installing the virtualbox guest additions.
I'm using the Debian Lucid non-free repository to install Virtualbox. I have ECC ram and RAID 5 hard disks, and have noticed no corruption outside of virtualbox 3.2.0. After downgrading to 3.1.8, all problems went away.

If there's anywhere I can look for diagnostic information about this issue, please let me know. Otherwise I just have to stay on 3.1.8 for now, as I can't risk image corruption.

[Madox]

Same problem trying to Install Lucid AMD64 Guest on 3.2.0 on Lucid AMD64 Host. Installer will report file IO errors.

I386 guest will install correctly but fail to boot fully.

[Madox]

Found a temporary workaround. Moving the VDI image from Storage Controller 1 (AHCI) to Storage Controller (PIIX4) works.

Resolved problem with Win7 32 Guest too!

Guess it has to do with :
New New Storage I/O subsystem – VirtualBox 3.2 offers a completely re-worked virtual disk subsystem which utilizes asynchronous I/O to achieve high-performance whilst maintaining high data integrity;

This problem only occurs for me on Ubuntu Lucid Lynx x64 Host with SSD. No issues on WinXP 64 Host.

[mjh_ca]

Confirmed - I am seeing the exact same behavior with Virtualbox 3.2.0. Ubuntu 10.04 x64 host, Windows 7 x64 guest. Host disk is an SSD as well.

Getting random errors when attempting to run Windows 7 installer - either blue screens or errors related to file corruption.

[HenriTouvent]

Got a lot of problems after upgrade to Virtualbox 3.2.0 for Ubuntu 10.04 ("Lucid Lynx") i386.
External drive not shown, loop after installing Servicepack2 in WinXP, system halts etc.
Could I go back from Virtualbox 3.2.0 (Ubuntu 10.04 ("Lucid Lynx") i386) to version 3.2.0 for Ubuntu 9.10 ("Karmic Koala") i386? Is this version supported by 10.4, Lucid Lynx? Just wait for newer version
Henk

[Sasquatch]

There is a known issue that SATA can give some issues during installation of an OS inside VB. Change to IDE during installation and things will go smooth. After installation, you can switch back to SATA (in case of Linux Guest). Windows Guests need the driver first before SATA can be used as boot controller.

[jth]

When copying a 10 GB Windows XP hard disk image over the network to a new virtualbox 3.2 install, it has corrupted my /home ext4 file system beyond repair on 3 occasions.

This is the host filesystem, not the guest. I thought it might be some other problem until I saw this topic. I wonder if the problems are related. I don't see any issues with 3.1.8. This is with a fairly vanilla Ubuntu 10.04 64 bit install with separate /home partition.

[Sasquatch]

When copying a 10 GB Windows XP hard disk image over the network to a new virtualbox 3.2 install, it has corrupted my /home ext4 file system beyond repair on 3 occasions.

This is the host filesystem, not the guest. I thought it might be some other problem until I saw this topic. I wonder if the problems are related. I don't see any issues with 3.1.8. This is with a fairly vanilla Ubuntu 10.04 64 bit install with separate /home partition.

What? Huh? You're saying that your host got a corrupted file system because you only copied a file of 10 GB? That hardly sounds like a VB problem, but a hard disk problem. In other words, physical hardware. It can also be a bug in the file system itself to cause this. There is no evidence that VB is directly responsible for it, other than the file happens to be a VDI.

[jth]

Indeed, my problem is not virtualbox-related. After 3 problems and no problems after 2 weeks with version 3.1.8, I was too quick to blame VB even if it didn't seem reasonable. However after two weeks running clean on 3.1.8 my file system is corrupt again so this is not virtualbox's fault. Sorry about the false alarm.

[JoeSchneider]

I had a similar problem with VirtualBox 3.2.0, running on Ubuntu 10.04 amd64 host and a Ubuntu 10.04 x86 guest. I did have some issues installing 10.04, but finally got it installed. I was attempting to do some embedded systems compiling and had downloaded LTIB. During compilation while compiling bash for the target, the ext4 guest filesystem got an error and it was remounted read-only. Confused, I wiped the install and redid it - and found the exact same issue reoccur at exactly the same compilation step. I then switched to a Win7 host and the build went fine. If my data is good, this issue isn't just limited to OS installation.

[aeichner]

We identified a bug which can cause data corruption. It happens with VDI images only and only if the image is growing. Because we are still unable to reproduce the issue it would be great if you would try the testbuild below. Please open a bug in our bugtracker if the corruption is still there and attach the VBox.log. Thanks for your help!

Linux amd64: http://www.virtualbox.org/download/test ... r62398.run

[aeichner]

We further investigated this and are able to reproduce data corruption if the image is on a ext4 partition. ext4 contained a bug which could lead to data corruption under certain circumstances. The Linux kernel used in Ubuntu Lucid Lynx doesn't contain the fix so far.
Can you please try with 3.2.4 and store the image on another filesystem (ext3 for example)?

[jth]

ext4 contained a bug which could lead to data corruption under certain circumstances. The Linux kernel used in Ubuntu Lucid Lynx doesn't contain the fix so far.

Thanks for the info ... do you have the kernel bugid so we can track the fix in ubuntu?

[Sasquatch]

ext4 contained a bug which could lead to data corruption under certain circumstances. The Linux kernel used in Ubuntu Lucid Lynx doesn't contain the fix so far.

You mean to say that Ubuntu 9.10 does have this fix? In other words, it only affects Ubuntu 10.04? If this is true, then I'm seriously questioning the safety of my VMs, as they are stored on a separate ext4 partition. Any idea which kernel does NOT have this problem? Like a vanilla kernel for example, that can be grabbed from http://kernel.ubuntu.com/~kernel-ppa/mainline/. When we know that, lets say, 2.6.33.5-lucid does not show this problem, users can install this kernel instead for the time being to prevent FS corruption.

[ddehnhard]

I've been bitten by this too and second that it would be nice to get clear information about it (as far it's known).
I experienced data loss several times (VM continues to work, but lost previously saved data) and disk corruption with two VMs (guest failed to boot).

I did some research on the net and found the following informations:

The bug with async I/O and ext4 mentioned above seems to be https://bugzilla.kernel.org/show_bug.cgi?id=16165 and is not resolved at the moment. (Source: "Discuss the 3.2.4 release" in this forum)

The same source states that async I/O is a new feature implemented in VB3.2.

There is at least one other bug with ext4 async I/O, for files with more than 4GB, which is marked solved in 2.6.33.3 ("named ext4: fix async i/o writes beyond 4GB to a sparse file"), which means it's present in the Debian Squeeze and the Ubuntu Lucid standard kernels at the moment (at least I didn't found a notice about backports).

There are more bug reports and fixes for ext4, of which many are not yet in the Distro kernels (e.g. Ubuntu has this bug open: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/588069 to backport a bunch of them to the Lucid kernel), but I guess they are not as grave as the two above, since many people including me use ext4 successfully for more than a year (though my Virtualbox server has just been recently updated from ext3 to Debian Squeeze with ext4 and VB 3.2).

So it seems that it's indeed dangerous to use VirtualBox 3.2.x on ext4 systems until these ext4 bugs are fixed.

ext3 seems to be fine. I for one will revert to Virtualbox 3.1 for until that bugs are fixed, as I have to repair these machines anyway and I am not inclined to rebuild the whole server (which runs more than VB) just for this.

I have a guess that the data losses I experienced may have another cause, but I am not sure yet, so I'll open a seperate thread, if I get more evidence.

That's my knowledge about this problem at the moment.
I'll be happy to hear new information about, especially when it's solved of course.