Ticket #5495 (closed defect: invalid)

Opened 9 years ago

Last modified 9 years ago

Windows - Delayed write faild corrupts .VDI file

Reported by: andyp73 Owned by:
Priority: major Component: virtual disk
Version: VirtualBox 3.0.10 Keywords:
Cc: Guest type: Linux
Host type: Windows


Running VirtualBox 3.0.10 on a Windows XP SP3 host and Ubuntu 9.10 running as a guest. The hosts disk is formatted as NTFS and the .VDI images are compressed using Windows disk compression to save disk space. Ubuntu 9.10 is using ext3 partitions within a dynamic disk image.

When the .VDI file gets above 50GB (as reported by Windows Explorer) then "Windows - Delayed Write Failed" errors are generated and the contents of the ext3 partitions are unrecoverable.

This isn't a new issue, I believe it has been in all of the 3.0.xx versions and also in the 2.1.x and 2.2.x versions that I used.



VBox.log Download (61.8 KB) - added by andyp73 9 years ago.

Change History

Changed 9 years ago by andyp73

comment:1 Changed 9 years ago by andyp73

To clarify...

The 50GB reported by Windows Explorer is the file size. The "size on disk" is around 25GB due to the compression.


comment:2 Changed 9 years ago by klaus

Your log file tells a rather different story than the bug description above.

First of all, VirtualBox reported that it ran out of disk space (after more than 17 hours, apparently things continued without trouble afterwards). VirtualBox complained about a corrupted image pre-header immediately. Never seen that happen in out of disk space situations, as VirtualBox doesn't need to extend the file to write to the pre-header. Could be a side-effect of the file compression.

The VM continued successfully (there are a number of seamless resolution changes which wouldn't work unless the guest OS is alive).

Then, after 22 hours totally out of the blue the host OS started signalling file locking violations. Together with the "delayed write" messages you're getting apparently it looks to me like this is caused by Windows, not by VirtualBox. When accessing disk images, VirtualBox is a normal application, and by definition they can't cause such "delayed write" errors unless there is an OS and/or hardware malfunction.

Any more details? With the currently available information it seems like VirtualBox gets sabotaged.

comment:3 Changed 9 years ago by andyp73

I remember seeing the out of disk space warning as the VM paused itself. This in itself was odd as the host machine had, and still has around 20GB disk space free - it is a 160GB disk as a single NTFS partition.

When I started to see the "delayed write" messages the only way I could close the VM was to kill the running process.

It may be that this is an issue with Windows or its use of compressed files but I have seen this a number of times when the .VDI file gets above 50GB.

Is there any way to turn on additional logging within VirtualBox to see what happens if i provoke the failure again?


comment:4 Changed 9 years ago by klaus

The only way to get additional logging (the sources are your documentation...) would be to create a debug build of VirtualBox, set appropriate debug logging and reproduce. Debug builds have their own quirks though, as they do lots more consistency checking which can potentially lead to VM crashes which wouldn't happen with release builds. All in all not a walk in the park...

comment:5 Changed 9 years ago by andyp73

I think this can be closed. I have cleared some space on my hard drive and have been able to keep the file uncompressed and it is currently at 51.3GB without anything untoward having happened to it.

You were probably correct that it is an issue with Windows that seems to affect large compressed files.

comment:6 Changed 9 years ago by klaus

  • Status changed from new to closed
  • Resolution set to invalid
Note: See TracTickets for help on using tickets.
ContactPrivacy policyTerms of Use