The disk usage is nearly 100% when the .vdi file of a VM is stored on a Seagate SSHD (#17392)

[merced]

---

[ModEdit; related ticket: #17392: The disk usage is nearly 100% when the .vdi file of a VM is stored on a Seagate SSHD]

---

I added a Seagate SSHD (Solid State Hybrid Drive, a HDD with a 8GB flash to speedup reading of frequently used files) to my desktop computer a few days ago. After I moved the .vdi file of a Win10 VM to that drive and started the VM, I found the disk usage in Task Manager of the guest OS is nearly 100% and the system response is notably slower than VMs whose .vdi files are stored in an HDD. The disk usage of the SSHD in host OS is extremely high (80% to 95%) too, but I did not run any application at that moment.
What is the matter?
Hardware config: AMD Ryzen7-1700, 16GB DDR4, 1TB HDD+2TB SSHD(Seagate ST2000LX001)
Host OS: Windows 10 x64 1709
VirtualBox version: 5.1.30
Guest OS: Windows 10 x86 1709, 3GB memory

I have reported this problem to the Bugtracker. The ticket number is 17392.

Task Manager of Host OS

host2.png (45.87 KiB) Viewed 15581 times

Task Manager of Guest OS

guest2.png (33.35 KiB) Viewed 15581 times

[socratis]

What is the matter?

I'm afraid that you'll have to ask your OS about that. VirtualBox is asking your OS for the files it reads/writes, and it doesn't care (or even know!) if the files are stored in an SSD/HD/CD/Floppy/NAS.

My gut feeling is that an overzealous antivirus is trying to scan all the new content. And besides the Usage percent in the TaskManager, there's also the Processes tab, which shows in more detail what's going on...

[merced]

To socratis:
Thank u. However the same VM (.vdi file) runs very well when it locates both in a HDD and in a SSD.
When it runs quite slowly in the seagate SSHD, Task Manager shows that the VirtualBox process occupies most of disk operation times.

[socratis]

I'm afraid that this doesn't change my answer at all.

[merced]

I have reported this problem to the Bugtracker. The ticket number is 17392.
I have also attached the zipped log file and 2 screenshots into the main post.

[socratis]

You just opened a bug for a perfectly normal behavior. I told you that you're looking at the wrong thing. VirtualBox doesn't know or care where your VDI resides. It is absolutely clueless and couldn't care less...

Check your guest's processes, what's using the CPU and the hard disk, and you'll have your answer...

I'll add the ticket information in the title...

[merced]

I have done some additional tests. This problem does not occur in guests of Win XP, WinSvr 2003, Win 7, nor Ubuntu Linux. It only occurs in Win 10 and WinSvr 2016. When Windows Update is downloading updates in Win 2016 guests, other apps that use file system are almost blocked. Almost all apps are extremely slow permanently in Win 10 guest.
Maybe it is not a defect of VirtualBox. One possible reason is that the acceleration algorithm (using flash memory as a cache) of Seagate SSHD disk does not adapt to some conditions. It is difficult to anaylze this problem because Seagate SSHD disk is a blackbox.

[socratis]

Maybe it is not a defect of VirtualBox.

I would say yes. Remember that I told you to check the processes to find out what's doing all that I/O? Now you know for sure. For my VM sitting on a USB3 (and not my usual SSD), it's the Windows Defender. I've disabled the updates...

[The Raven]

One possible reason is that the acceleration algorithm (using flash memory as a cache) of Seagate SSHD disk does not adapt to some conditions.

Almost certainly true.
I had similar problems on bare metal with those drives, albeit probably with older firmware than yours.
When I looked at it (some years ago now), the problem appeared to be the method they used for populating and de-staging from the cache.
I assumed they used a combination of most recently used + most actively used. or something similar.
Depending on the I/O load and access pattern, you could quite easily force cache pollution to occur.
This would result in almost all the active I/O going to the disk platter (not the cache) with the added overhead that the disk controller was also attempting to de-stage data from the cache (to the disk platter) *AND* re-fill the cache.
Result - very slow disk I/O.