A pending patch series targeting VirtIO-FS would let the shared file-system service guest VM I/O requests synchronously rather than always funnelling them through asynchronous queues — and early results reported by Phoronix point to substantial performance headroom, particularly on the small, scattered, metadata-heavy workloads that have historically been VirtIO-FS's weak spot.
VirtIO-FS is the de facto mechanism for sharing directories between a QEMU/KVM host and its guest virtual machines, replacing the older 9p transport and underpinning everything from private cloud nodes and CI build farms to edge deployments. The problem the new work addresses is overhead: under today's implementation, requests are routed through an asynchronous queueing path — leaning on io_uring — even when a synchronous handoff would be quicker. Every extra hop costs context switches and queueing latency, and those costs compound on precisely the workloads that matter most in real data centres — many small file operations, directory metadata churn, and scattered reads and writes rather than large sequential transfers.
The proposed rework lets VirtIO-FS bypass that machinery where a synchronous path makes sense, cutting out queue round-trips per request. According to Phoronix's coverage, the benchmark improvements are pronounced on exactly those small and scattered I/O patterns, in cases where VirtIO-FS has trailed local file-system performance and, at times, virtio-blk. For operators, the headline is not a benchmark score but a conversion: lower per-request overhead translates either into more throughput from hardware already racked, or into equivalent guest performance at a measurably lower CPU cost on the host.
That trade-off is far from academic for anyone running dense virtualisation environments. In colocation and cloud deployments where host CPU cycles and rack-level efficiency directly shape capacity planning and unit economics, any DevOps or platform team running KVM/QEMU fleets — whether for virtual desktops, multi-tenant containers on VMs, or build-and-test infrastructure — is effectively betting on VirtIO-FS's performance curve: the file-sharing layer sits on the hot path of almost every guest workload that touches shared storage or configuration.
How the change works, briefly
The mechanics are straightforward but meaningful. VirtIO-FS currently defaults to an asynchronous, io_uring-backed servicing model. The series under discussion introduces a synchronous queue option so requests can complete inline, eliminating the queue-hop and associated context switch for each operation. The change follows a broader trend across the Linux storage stack toward hybrid sync/async I/O models — virtio-blk and io_uring itself have evolved along similar lines — and continues VirtIO-FS's steady maturation alongside earlier milestones such as DAX support, locking improvements, and multi-queue operation.
Caveats and what to watch
Crucially, the code is out-of-tree and unmerged. The reported figures signal potential, not a production guarantee, and final performance will depend on how the series lands in the kernel, whether it survives review in its current shape, and on matching updates to guest kernels and the virtiofsd userspace daemon. Teams evaluating VirtIO-FS against alternatives today should treat these results as a directional indicator rather than a spec-sheet number.
The narrowing gap with paravirtualised block devices also matters strategically. As VirtIO-FS closes in on virtio-blk for the small-I/O profiles that previously forced a choice, the incentive to fall back on 9p or network block storage for shared-filesystem workloads weakens considerably — simplifying stacks rather than merely accelerating them.
The open question for the community is timing. If the series is posted for review, revised, and merged into a mainline release cycle, the practical picture becomes concrete: named releases, packaged virtiofsd builds, and reproducible benchmarks. Until then, the honest read is that VirtIO-FS's performance ceiling may be about to rise considerably — and that anyone sizing hosts around shared-filesystem overhead should keep this series on their watchlist.
Source: Phoronix
一組針對 VirtIO-FS 的修補程式系列正在等待合併，其作用是讓共享檔案系統服務可以同步處理客戶虛擬機的 I/O 請求，而不必一律經由非同步佇列處理——Phoronix 報導的初步結果顯示，效能提升空間相當可觀，尤其在小型、零散、以 metadata 為主的工作負載方面，這類負載一向是 VirtIO-FS 的弱點所在。
VirtIO-FS 是目前 QEMU/KVM 主機與客戶虛擬機之間共享目錄的事實標準機制，取代了較舊的 9p 傳輸層，支撐著從私有雲節點、CI build farm 到邊緣部署的各種應用。此次改動針對的問題是額外開銷：在現行實作中，即使同步交接更快，請求仍會經由非同步佇列路徑處理——依賴 io_uring。每一層額外轉接都涉及 context switch 和佇列延遲，而這些成本恰好在現實數據中心中最關鍵的工作負載上不斷累積——大量小型檔案操作、目錄 metadata 頻繁變動，以及零散的讀寫，而非大型順序傳輸。
建議中的重新設計讓 VirtIO-FS 在適合同步路徑的情況下繞過這套機制，省卻每個請求的佇列往返。根據 Phoronix 的報導，基準測試的改進正是在這些小型及零散 I/O 模式中最為明顯——過往 VirtIO-FS 在這類場景下落後於本地檔案系統，有時亦不及 virtio-blk。對維運人員而言，重點並非一個基準測試分數，而是實際轉化：每請求開銷降低，意味著既有的機架硬件可以提供更高吞吐量，或者以明顯更低的主機 CPU 成本達到同等的客戶虛擬機效能。
對任何運行高密度虛擬化環境的人來說，這種取捨絕非紙上談兵。在主機 CPU 時間和機架層面效率直接影響容量規劃和單位經濟效益的 colocation 及雲部署環境中，任何運行 KVM/QEMU 機群的 DevOps 或平台團隊——不論用於虛擬桌面、VM 上的多租戶容器，還是 build-and-test 基礎設施——本質上都在押注 VirtIO-FS 的效能曲線：檔案共享層幾乎處於每一個接觸共享儲存或配置的客戶工作負載的關鍵路徑上。
變動原理簡述
改動手法簡單直接，但意義重大。VirtIO-FS 目前預設採用由 io_uring 支撐的非同步處理模式。本次討論的修補程式系列引入同步佇列選項，使請求可以 inline 完成，省卻每個操作的佇列轉接和相應的 context switch。此改動符合 Linux 儲存堆疊整體向混合 sync/async I/O 模式發展的趨勢——virtio-blk 和 io_uring 本身亦沿類似方向演進——並延續 VirtIO-FS 逐步成熟的趨勢，此前已有 DAX 支援、locking 改進和 multi-queue 操作等里程碑。
注意事項及觀察重點
必須強調的是，相關程式碼目前仍在 out-of-tree，尚未合併。已公佈的數據反映的是潛力，而非生產環境的保證；最終效能將取決於該修補程式系列如何進入 kernel、能否以現有形式通過 code review，以及客戶 kernel 和 virtiofsd userspace daemon 是否配合更新。目前正評估 VirtIO-FS 與其他方案的團隊，應將這些結果視為方向性指標，而非規格表上的數字。
與半虛擬化 block device 的差距收窄同樣具有策略意義。隨著 VirtIO-FS 在以往被迫做出選擇的小型 I/O 場景中追近 virtio-blk，為了共享檔案系統工作負載而退回 9p 或網絡 block storage 的誘因已大為減弱——這不僅是加速堆疊，更是簡化堆疊。
社群尚待解答的問題是時間表。若修補程式系列正式提交 review、修訂並合併到 mainline release cycle，實際圖景便會變得具體：明確的版本號、已打包的 virtiofsd build，以及可重現的基準測試結果。在此之前，誠實的判斷是：VirtIO-FS 的效能上限可能即將大幅提升——任何根據共享檔案系統開銷來規劃主機規格的人，都應將這個修補程式系列列入觀察清單。
資料來源：Phoronix