High I/O on SharedFolders hangs system

[dsiercks]

Running a deep file scan (IdentityFinder) within a 32bit Windows XP guest on a Shared Folder is causing multiple VMs to independently hang. Guest OS remains somewhat responsive (right click on start bar provides menu) but Explorer or other applications remain unresponsive.

Task Manager is still running/updating and shows 0% CPU usage.

I've included virtual box log. Machine went unresponsive at 10 minutes. Resized window at 35 minutes to provide timeline. Host OS shows vmware process as utilizing between 13-40% cpu utilization.

Host OS is Fedora 19 with yum packages "akmod-VirtualBox Virtualbox" installed.

[dsiercks]

Identity Finder:http://www.identityfinder.com/

System will scan the first ~4,000 files as normal but then Explorer and the OS will hang.

[Frank Mehnert]

Are you able to stop that scanning application?

[dsiercks]

It says its attempting to stop, but its been doing that for the past 20 minutes now.

I've killed Identity Finder in Task Manager and Explorer is still unresponsive though I am able to open new applications such as firefox..

I'm not sure it matters, but I'd been doing the same type of scans using Shared Folders on VMWare using a similar setup on a different machine/host OS.

Thank you for the reply! Let me know if I collect any other information.

[davidjb]

I think this may be a similar/same issue I'm facing.

Ubuntu 13.04 Host, CentOS 6.4 guest (using VirtualBox 4.2.16 as part of Vagrant 1.2.7) and I'm finding that when effectively any I/O happens on the shared folder that gets configured, the CPU usage of the host VBox process runs at 100% CPU (for however many CPUs/cores the VM is configured for).

For example, if I run while [ 1 ]; do ls /vagrant; done; on the guest, the guest's CPU usage is reporting usage around 10% (6% for bash, 4% for sshd). However, whilst this infinite ls call is running, the VBox process is consuming about 117% CPU (1 CPU + extra).

A data transfer comparison shows a file copy from host to client via the shared folder ends up running at about 8.8 MB/s (maxing the CPU along the way). By contrast, a direct copy on the host itself is 370 MB/s (it's an SSD).

In any case, this issue means the effective I/O from the guest side of things is greatly diminished - making shared folders unusable.

[aeichner]

Please reopen if still relevant with a recent VirtualBox release.

[vbox_richard]

I just ran into this particular problem on an up-to-date version of VirtualBox. The exact version is "VirtualBox VM 5.0.24_Ubuntu r108355 linux.amd64". I can reproduce the problem; after writing 60k to 100k files to the shared folder the same symptoms as described above emerge. Checking the process with sysdig shows the log entry: "VirtualBox (48944) < recvmsg res=-11(EAGAIN) size=4096 data= tuple=NULL" over and over again.

[aeichner]

Can you please attach a VBox.log of the affected VM?