3

I've got a Windows 10 virtual machine running on Ubuntu 18.04 host (QEMU 2.11). I've created a shared folder with the command line parameters -netdev type=user,id=smb0,smb=/mnt/ntfs,restrict=on -device virtio-net-pci,netdev=smb0. Mostly the disk works great, but in some use cases it shows very slow write performance, as can be seen in the last test result of CrystalDiskMark (random 4K, 1 queue, 1 thread): only about 0,09 MB/s (22 IOPS).

CrystalDiskMark results: 4KiB Q1T1: 0,089 MB/s

This shows up in practice also: creating and saving a 600 MB panorama from Autopano Giga 4.4 takes 1 h 45 min to the shared drive, versus 1 min 30 s to the normal drive. Copying the file takes only about 5 seconds.

Things I've tried without noticeable improvement:

  • Changing host disk from NTFS HDD to EXT4 SSD.
  • Modifying some performance options in the temporary QEMU smb.conf and reloading it with smbcontrol all reload-config.
  • Changing QEMU command line options for the network (restrict on/off, different device type etc.).

Can this performance problem be fixed?

UPDATE

I think I've isolated the problem to QEMU's user mode networking.

I removed the shared folder option from QEMU command line and launched a normal Samba server instead, with mostly the same config. The performance problem persisted when I mounted the drive through the user mode internal network (//10.0.2.2/ -> 127.0.0.1 on host). When I instead mounted it through another, bridged (tap) network device using the external (home network) IP (//192.168.1.11/), write speed went up to almost 28 MB/s (6800 IOPS)!

Reading the source code revealed that CrystalDiskMark uses DiskSpd to do the actual tests. If I deciphered the code correctly, the command line for the test in question is:

diskspd -b4K -d5 -o1 -t1 -W0 -r -S -w100 -Z4K [file]

DiskSpd has a linux version, for which the following is mostly equivalent:

diskspd -b4K -d5 -o1 -t1 -W0 -r -Sd -w100 -Zr [file]

To rule out the possibility that Samba was working badly on the loopback interface, I tested the speed also on the host side (mounted with mount -t cifs). Running the above command showed excellent performance: 90 MB/s or 23000 IOPS; or a tenth of that with hardware buffering disabled (-Sh).

So I think the culprit must be QEMU user networking. The version of QEMU on Ubuntu 18.04 is quite old, and I have no idea whether this applies to recent versions or not.

Since a normal Samba server over bridged network works fine, I'll use it as a workaround, though I would have preferred to use the internal shared folder mechanism :/

  • Do you have the same problem if you're using qemu's default nic type (e1000) instead of virtio-net-pci? – mosvy Jul 6 at 18:30
  • Yes, I forgot to mention that I tested it also :) – Jaripekka Juhala Jul 6 at 20:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.