WSL 2を使ってWindowsとLinuxを行き来しながら作業している人にとって、ファイルI/Oの速度は常に気になるポイントです。2026年5月、WSL 2に新しい改善が入り、virtiofsを使ったクロスOSのファイルアクセスがさらに高速になりました。Hayden Barnes氏のブログ記事「WSL 2 is getting faster Windows file system access」によると、これまで残っていた最後の大きなボトルネックが解消され、Windows側のファイルを扱うワークロードがよりスムーズに動作するようになるとのことです。WSLのファイルアクセスはどう進化してきたのかWSLのファイルアクセスは時代に合わせて進化しています。初期のWSL 1の頃は、LinuxプロセスがWindowsカーネル上で直接動く仕組みだったため、/mnt/cなどのWindowsドライブへのアクセスはNTFSにほぼ直結していました。ファイル操作が多い作業でも高速に動作していたのはこのためです。しかし、WSL 2(2019年)では軽量VM上で本物のLinuxカーネルを動かす方式に変わり、互換性やLinuxネイティブの性能は向上した一方で、Windows側のファイルアクセスはPlan 9(9P)プロトコル経由になりました。9Pは動作は安定しているものの、1回の操作ごとに64 KBのメッセージサイズ制限があり、小さなファイルを大量に扱う処理ではオーバーヘッドが目立ちます。そこでMicrosoftはvirtiofsを実験的に導入し、共有メモリベースの高速なファイルアクセスを段階的に改善してきました。2021年以降、デバイス再利用やmmapの改善などが進み、今回のDMA層の最適化でさらに一歩前進した形です。今回の改善ポイント: デバイスごとのDMAプールHyper-V上のVMでは、DMAを行う際に4GB以下の領域に確保されたSWIOTLBプール(バウンスバッファ)を使います。これまではWSL 2内のすべてのvirtioデバイスがこのプールを共有しており、/mnt/cや/mnt/dのvirtiofs、さらにネットワークアダプタまで同じ領域を取り合っていました。2026年5月にマージされたPR#40654によって、各virtioデバイスが専用のDMAプールを持つようになり、ドライブ間やネットワークとの競合が解消され、I/Oが詰まりにくくなります。この改善で恩恵が大きいのは、Windows 側にあるコードを Linux 側でビルドするようなワークフローです。たとえば、C:\Users\you\code にあるプロジェクトを /mnt/c から cargo build や npm install で処理する場合、膨大なファイルアクセスが発生します。今回の改善で、この「クロス OS I/O」のボトルネックがさらに減り、ビルド時間の短縮が期待できます。また、virtiofsと同じDMA基盤を使うVirtioProxyネットワークも高速化の恩恵を受けます。最適な環境を実現するポイントは次の通りです。.wslconfigの[wsl2]セクションでvirtiofs=trueを有効化wsl.exe--update--pre-releaseで最新カーネルに更新WSL 2の割り当てRAMを1GB以上に確保(SWIOTLBに最低64MB必要)なお、virtiofsはまだデフォルトではなく、標準は引き続きPlan 9です。今後も改善は続いていく見込みです。まとめ: WSLのクロスOS I/Oは着実に進化中WSL 1のDrvFs、WSL 2の9P、virtiofsと、WindowsとLinuxの間のファイルアクセスは世代を重ねるごとに高速化されています。今回のDMA層の改善は、virtiofsの性能をさらに引き上げる重要なステップであり、WindowsとLinuxを横断する開発者にとって確かなメリットがあります。WSLのファイルアクセス速度の遅さに不満があった開発者の方は確認してみるとよさそうです。