WSL で /mnt/c 配下のファイル操作が極端に遅い

WSL2 から /mnt/c を触るとファイル単位で Windows 側と通信するため、小さなファイルを大量に扱う操作が桁違いに遅くなる。
プロジェクトを Linux 側のファイルシステムへ移すのが根本的な解決になる。

#wsl #wsl2 #performance #filesystem #mnt

公開: 2026-08-24更新: 2026-10-02

実行例あり（2026-10-02 に実環境で検証）

要約

WSL2 の Linux 側から /mnt/c を読み書きすると、OS をまたいだファイル共有を経由する。
1 ファイルずつのやり取りに変換されるため、ファイル数が増えるほど遅くなる。Working across file systems（新しいタブで開く）は、パフォーマンスが要るファイルは作業する OS 側のファイルシステムに置くよう明示している。

# 遅い: Windows 側のディスクを Linux から触っている
cd /mnt/c/Users/me/project && npm install
 
# 速い: Linux 側で完結する
cd ~/project && npm install

cp 1 回のような単発操作では差が見えにくく、npm install や git status のように数万ファイルを触る操作で一気に表面化する。

実行例

findmnt で見ると /mnt/c は C:\ を共有した 9p、/ は ext4 としてマウントされていた。
同じ 300 個のファイル作成は、ext4 側のホームでは 0.015 秒、/mnt/c 側では 0.625 秒かかり、約 40 倍の差が出ている。

$ wsl --version
WSL バージョン: 2.6.3.0
カーネル バージョン: 6.6.87.2-1
WSLg バージョン: 1.0.71
MSRDC バージョン: 1.2.6353
Direct3D バージョン: 1.611.1-81528511
DXCore バージョン: 10.0.26100.1-240331-1435.ge-release
Windows バージョン: 10.0.26200.9550

$ findmnt -o TARGET,SOURCE,FSTYPE /mnt/c
TARGET SOURCE FSTYPE
/mnt/c C:\    9p

$ findmnt -o TARGET,SOURCE,FSTYPE /
TARGET SOURCE   FSTYPE
/      /dev/sdf ext4

$ time (mkdir -p ~/iobench && cd ~/iobench && for i in $(seq 300); do echo payload > f$i; done)
real	0m0.015s
user	0m0.004s
sys	0m0.009s

$ time (mkdir -p /mnt/c/Users/Public/iobench && cd /mnt/c/Users/Public/iobench && for i in $(seq 300); do echo payload > f$i; done)
real	0m0.625s
user	0m0.007s
sys	0m0.033s

— 2026-10-02 時点の出力

検証環境

検証日

2026-10-02

実行環境

local host (Windows 11 Home, Docker 29.8.0)

バージョン

Node.js 22.14.0
npm 10.9.2
Git 2.48.1.windows.1
Docker 29.8.0

この記事の「実行例」は、上記の環境で実際にコマンドを実行して得られた出力をそのまま掲載しています。再現手順はリポジトリの検証スクリプトとして管理し、定期的に再実行して出力を更新しています。

よくある原因

プロジェクトの置き場所: Windows 側のホームにリポジトリがあり、ビルドだけ WSL で回している構成が典型である。
この構成は跨ぎアクセスを最大化する。
小さなファイルが大量にある: node_modules は数万個の小さなファイルの塊で、1 個ずつのやり取りが積み上がる。git status も全ファイルの状態を確認するので同様に遅い。
ウイルス対策のスキャン: 跨ぎアクセスは Windows 側のファイル操作として扱われるため、リアルタイム保護の対象になる。
アクセス回数が多いほど影響が出る。
ツールの往復: Linux 側のエディタと Windows 側のフォーマッタを交互に使うと、どちらの方向でも跨ぎが発生する。
WSL1 との混同: WSL1 は Windows のファイルシステム上で動いていたため /mnt/c が速く、代わりに Linux 側の I/O が遅かった。
WSL2 では前提が逆になっている。

解決策

1. Linux 側へ移す

mkdir -p ~/src
cp -r /mnt/c/Users/me/project ~/src/project
cd ~/src/project

git clone からやり直せるなら、そのほうが速く確実である。
移動後は npm install を Linux 側で実行し直す。
ネイティブモジュールは OS 依存のため、node_modules をコピーして持ち込まない。

2. Windows からは UNC パスで開く

エクスプローラのアドレス欄に次を入力すると、Linux 側のファイルをそのまま扱える。

\\wsl.localhost\Ubuntu\home\user\src\project

Set up a WSL development environment（新しいタブで開く）が説明するとおり、この方向のアクセスは Windows 側のアプリから利用する前提で用意されている。

3. VS Code は WSL 側で開く

cd ~/src/project
code .

WSL 拡張機能が入っていれば、エディタの UI だけが Windows 側で動き、ファイル読み書きと拡張機能の処理は Linux 側で完結する。

4. 除外設定で緩和する

/mnt/c を使い続ける事情がある場合は、Windows セキュリティの「ウイルスと脅威の防止」からリポジトリのフォルダーを除外に追加する。
跨ぎ自体は残るので改善は部分的だが、体感差は出る。
除外は開発用フォルダーに限定する。

要約

実行例