High I/O causing filesystem corruption

[martyscholes]

In my testing, I've found the performance hit to be too server to give up host cache. Are there any tunables or techniques to reduce the above effect.
(such as running 'sync' out of cron). The idea would be to flush things out earlier and more consistantly.

I was thinking the same thing. It's a little ghetto, but having cron flush the write cache periodically is a tunable solution somewhere in between the two extremes.

[Kartweel]

Has anyone got a solution to this? Someone suggested running under ZFS. I am doing that using ZFS on Linux and still have this exact issue.

I've also disabled Ignore Flush Requests, so flush requests should go through the ZIL

Disabling host O/S cache actually seems to make it worse. VMs become very unresponsive and slow.

Only seems to happen on linux hosts. Probably have spent 100 hours trying to solve this, or at least get a work around. Pretty much tried everything, except for dumping virtualbox. Whenever I copy a large file in another VM, it crashes all much other VMs.

It must be a virtualbox issue with linux hosts and not a direct issue on the host (as suggested with the write buffers), because the linux host runs fine and is responsive the entire time. I'd think if it was the write buffer then the linux host would also become unresponsive?

I've also had problems with windows guest VMs disk access, but they seem to be more resilient than linux guest VMs (maybe they just have a longer timeout?)

[martyscholes]

You have me curious. When you copy a large file, does the host run low on memory? I am wondering if the copy is somehow loading up read buffers on the host and starving the guests?

I know it is a shot in the dark.

[Kartweel]

Host has 32GB of RAM with plenty free, so I don't think it is a memory issue.

[reylon]

One of the most important answers is right there - if you're on a Linux host and doing heavy disk I/O, do not use the host cache for the VMs, ever. The Linux I/O subsystem not very smart, it batches gobs of dirty pages in the filesystem cache, and when it runs out of free memory, flushes out everything to disk. That can take quite a long time (minutes) and there's nothing VirtualBox can do about it.

Unfortunately also with no host cache there is the problem. From years I use "owncloud" solution, writing data on a virtualbox shared folder working perfectly. Just 3-4 users but with 50GB data each and thousands of little file to sync and to backup. All fine for years! Now I updated linux to debian 9, used the same design with ownclowd and nextcloud last version but on uploading both solution crash. The guest crash randomly seems for I/O problem with any symptom and need restart; probably the last cloud software version performed the I/O speed. Problem on virtual box 5.1.x and also on 5.2. I not understand why virtualbox not limit the application to the disk writing speed as happen when you copy a file for sample. What can I do to solve?

[socratis]

You didn't just wake up a 5-year-old dead thread, did you? Do you know where VirtualBox was on 2013-01-03 when this discussion last took place? 4.2.6!

Locking this one. It's considered ancient in software terms...