Ubuntu 18.04ホスト（QEMU 2.11）で実行されているWindows 10仮想マシンがあります。コマンドラインパラメータを使用して共有フォルダを作成しました-netdev type=user,id=smb0,smb=/mnt/ntfs,restrict=on -device virtio-net-pci,netdev=smb0。ほとんどの場合、ディスクは正常に動作しますが、一部のユースケースでは、最後のテスト結果に示されているように書き込みパフォーマンスが非常に遅くなります。クリスタルディスクマーク（任意4K、キュー1個、スレッド1個）：～0.09MB/s（22IOPS）に過ぎません。
これは実際にも現れます。 Autopano Giga 4.4で600MBのパノラマを作成して共有ドライブに保存するには1時間45分かかり、通常のドライブには1分30秒かかります。ファイルのコピーには約5秒しかかかりません。
顕著な改善なしに試したこと：
- ホストディスクをNTFS HDDからEXT4 SSDに変更します。
- 一時QEMU smb.confでいくつかのパフォーマンスオプションを修正してください
smbcontrol all reload-config。 - ネットワーキング用のQEMUコマンドラインオプションを変更します（制限の設定/解除、さまざまなデバイスタイプなど）。
このパフォーマンスの問題を解決できますか？
修正する
私は問題をQEMUのユーザーモードネットワーキングに分けたと思います。
QEMUコマンドラインから共有フォルダオプションを削除し、デフォルトで同じ構成で汎用Sambaサーバーを起動しました。ユーザーモードの内部ネットワーク（ホストシステムの// 10.0.2.2 / -> 127.0.0.1）を介してドライブをマウントすると、パフォーマンスの問題が持続します。外部（ホームネットワーク）IP（://192.168.1.11/）を使用して別のブリッジ（タブ）ネットワークデバイスを介してマウントした場合、書き込み速度はほぼ28MB / s（6800 IOPS）でした！
CrystalDiskMarkが使用するソースコードを読むディスク速度実際のテストに進みます。コードを正しく解読した場合、関連テストのコマンドラインは次のようになります。
diskspd -b4K -d5 -o1 -t1 -W0 -r -S -w100 -Z4K [file]
DiskSpdではLinuxバージョン、以下はほとんど同じです。
diskspd -b4K -d5 -o1 -t1 -W0 -r -Sd -w100 -Zr [file]
ループバックインターフェースでSambaが正しく機能しない可能性を排除するために、ホスト側でも速度をテストしました（マウントを使用mount -t cifs）。上記のコマンドを実行すると、優れたパフォーマンスが表示されます。 90MB/s または 23000 IOPS またはハードウェア・バッファリングがディセーブルの場合（-Sh）の 1/10 です。
だから犯人はQEMUユーザーネットワークであるに違いないと思います。 Ubuntu 18.04のQEMUバージョンはかなり古く、これが最新バージョンで動作するかどうかわかりません。
ブリッジされたネットワーク上の一般的なSambaサーバーはうまく機能するため、内部共有フォルダメカニズムを使用することをお勧めしますが、これを回避策として使用します。