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).
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?
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 :/