Freeze/stall on fstrim

[SkyBeam]

I am regularly facing VM freezes/stall where the VM would not repsond any more. It occasionally happened on some Gentoo Linux guest and rather frequently happens to Windows 10 and 11 guest (latest build and patch).

When the VM is freezing I can see 100% disk activity in my Windows 10 22H2 task manager on the disk where the VM disk image is located. In my case the disk is maxing out at about 300MB/s read rate at about 0% write rate though.

I could track down the issue to a potential problem with SSD trim support.
To save disk space I did enable trim on the virtual disk:

Code: Select all

vboxmanage storageattach "vmname" --storagectl "SATA" --port 0 --device 0 --discard off

Weirdly it seems to happen randomly and I cannot trigger it by using "fstrim" on my Linux guest. But somehow the disk queue randomly seems to lock up itself sticking to maximum read rate. I could also not find anything useful in the logs. Disabling the discard option seems to resolve the problem but obviously leaving me without trim support for the disk images.

Is anyone able to confirm the issue or even point me to fix/workaround?

I think those "stalled VMs at max disk activity" events appear more frequently since VBox 7 and seems unrelated to any other VM setting or even the guest addons installed as I am getting freezes no matter if guest addons are installed, which version or even when they are not installed at all.

[fth0]

I could track down the issue to a potential problem with SSD trim support.

A few years ago, when I started using the auto-discard feature of VirtualBox myself, I encountered the same issue. The solution for me was to enable the Host I/O Cache for the SATA Controller, and I'm using it since without issues.

My theory regarding the guest OS is that Windows tends to trim the SSD right after deleting files, so there could be races between unfinished delete operations and trim operations. Linux guests typically trim the SSD at specific times only (e.g. via cron), so collisions are rather unlikely.

[SkyBeam]

A few years ago, when I started using the auto-discard feature of VirtualBox myself, I encountered the same issue. The solution for me was to enable the Host I/O Cache for the SATA Controller, and I'm using it since without issues.

I was playing with these settings too. The thing is in VBox 7 I am getting erradical freezes no matter if the host I/O cache is on or off. I even tried different controller types at no avail.

My theory regarding the guest OS is that Windows tends to trim the SSD right after deleting files, so there could be races between unfinished delete operations and trim operations. Linux guests typically trim the SSD at specific times only (e.g. via cron), so collisions are rather unlikely.

If there is a race condition more frequent trim is more likely to trigger the issue. This theory also explains why it happened to me on Linux guest only about 2 times yet and on Windows very often right after booting into the GUI.

I also found a couple of reports about freezes with high I/O load in older forum/bug-reports/mailing-lists but no actual solution.

So bottom line is that there might be a critical bug in the trim/discard code which is unresolved.