[SOLVED]BLKCACHE_IOERR when on a secondary partition

[SilentStorm_QC]

My host machine is on Arch Linux amd64. My root partition(ext4) is not big enough to hold my VMs, so I run my VMs from a different partitions, which is in NTFS(which I use for storage across Linux and Windows). This so far my first VMs, so I don't know if it's OS-specific.

I am trying to install Gentoo on a VM for educationnal purpose, but I come across a problem. When, inside the vm, I try to mount a partition of the virtual hard drive, the VM crash and send me this error:

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

An error has occurred during virtual machine execution! The error details are shown below. You may try to correct the error and resume the virtual machine execution.

The I/O cache encountered an error while updating data in medium "ahci-0-0" (rc=VERR_DEV_IO_ERROR). Make sure there is enough free space on the disk and that the disk is working properly. Operation can be resumed afterwards.

Error ID: BLKCACHE_IOERR
Severity: Non-Fatal Error

---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Sometimes, it also corrupt the files and I cannot even open the VM anymore and I have to start over. fsck does not help, as it detects problems but cannot fix them.
However, it seems like if I DO run my VMs from my root partition(in ext4) on my host machine, the problem doesn't appear and everything works correctly.

Is there a way to fix this so can run it on the secondary NTFS partition of my machine?

EDIT: Forgot to mention, I already tried to use a fix size disk and it didn't help. Enabling I/O cache on the SATA port still gets the disk corrupted, but I can get past the mount part. Doing this, however, sets the drive readonly as the OS think it's corrupted.

[Perryg]

Disk corruption is really serious.
First are you using RAW access with these guests?
Also NTFS is not native to Linux in as much as it needs to be translated. It could be a bad host package in some way, and where do you get your version of VirtualBox from?
I would also run a serious test on the partition that is having this issue as it might be a drive failing.

Finally if the host is not apple we can not talk about running Mac guests as it is against policy.

[SilentStorm_QC]

Thanks for the notice about Mac, I'll remove this line from the original post.
The disk corruption is about the virtual drive, not the NTFS partition
RAW accerss? I don't believe so, since I didn't touch anything with that. I juste setup the VM using mostly the default settings. Can you clarify what it is and where to check this?
I got VirtualBox from the official Arch Linux repos, using pacman -S virtualbox.
I will try to fsck the actual NTFS partition, just to be sure.

EDIT: Little mistake there, I had to use ntfsfix instead of fsck, since it's a NTFS partition. No error was detected. Maybe it's really something about VirtualBox emulating it as an ext4 partition that's causing the problem?

[Perryg]

I got VirtualBox from the official Arch Linux repos, using pacman -S virtualbox.

You may want to seek their assistance as well due to the fact that it is not the official version from virtualbox.org. IIRC they use the source code and compile their own version of VirtualBox.

If you were using RAW access you would know it.
You might want to also post a guests log file so we can see if there is something there that could point this in the right direction.

[SilentStorm_QC]

Here you go for the .log file! I'll try installing the official version from Oracle website and see if that fixes the problem

Edit: I just realised the log files didn't upload. Here is another log file from the official virtualbox website download.

[Perryg]

EDIT: Little mistake there, I had to use ntfsfix instead of fsck, since it's a NTFS partition. No error was detected. Maybe it's really something about VirtualBox emulating it as an ext4 partition that's causing the problem?

I would think that the file emulation would be meaningless since the host just sees a simple albeit large file. You could experiment with host io/cache enabled and disabled in the guests settings but I just have the strange feeling it is host related or something that was changed in the source code by the arch folks. We just don't see many issues about disk corruption and when we do it is almost always something host related.

[SilentStorm_QC]

Using the VirtualBox downloaded from the official website( the .run for all linux distribution), the problem is still there. It didn't fix it.

[mpack]

How much free space is on the host partition, the one where the VDI is located?

[SilentStorm_QC]

357 GiB left in that partition. I don't think that's the problem.

[Perryg]

Thanks for the log file. I see you are using fuse as your main storage. I don't have much experience with it but from what I have read this might ( and I say might ) be an issue.

[SilentStorm_QC]

Do you know of any alternative to FUSE? Maybe the one present on Ubutnu and other mainstream, supported system?

[Perryg]

Sorry no I don't. I don't use arch as host so it may be the default. Like I said in the beginning you should really ask the Arch folks what they think.

[SilentStorm_QC]

Fixed the problem!
I don't know if it's related to FUSE-system, but it seems like using a .vmdk virtual hard disk instead of a .vdi patches the problem. Don't know for other file types, but this one seems to work. I should have thought about trying that earlier....
Thank you for the support!