WSL2の/mnt/cはなぜ遅いのか｜git statusが35倍速くなった実測結果
概要
本記事ではWSL2から/mnt/c（Windows側のファイルシステム）にアクセスするときの速度について説明します。
VS CodeをRemote-WSLで開いたとき、画面に「このワークスペースはWindowsファイルシステム上にあるので、Linux側に移すことをお勧めします」という案内が出ました。
正直、体感できるほど差があるのか半信半疑だったので、実際に自分のブログのリポジトリで計測してみることにしました。
数字で見るとかなりはっきりした差だったので、共有しておきます。
それではやっていきましょう！
目次
計測方法
対象は自分が普段作業しているHexoブログのリポジトリで、ファイル数は約29,000個です。
同じリポジトリを、次の2つの場所にそれぞれ用意して比較しました。
/mnt/c/Programming/...- WSL2からWindows側のCドライブを経由してアクセスする従来のパターン
~/Programming/...- WSL2のLinuxネイティブファイルシステム上に直接置いたパターン
計測したのはgit statusと、ファイル一覧を取得するfindコマンドの2つです。
計測結果
まずは/mnt/c側の結果です。
/mnt/c
1 | time git status |
git statusだけで27秒もかかっていました。
これはさすがに毎回は待てない数字です。
続いて、同じリポジトリをLinuxネイティブ側にコピーして同じ計測をした結果です。
Linuxネイティブ側
1 | time git status |
git statusは0.78秒、ファイル一覧の取得も0.17秒まで縮みました。
git statusで約35倍、ファイル一覧の取得では約85倍の差になります。
なぜここまで差が出るのか
WSL2は、Windows側のドライブをDrvFsという仕組み経由でマウントしています。
これはLinux側から見ると、いわばネットワーク越しのファイルシステムに近い動き方をしていて、ファイル1つあたりのアクセスに毎回オーバーヘッドが乗ります。
ファイル数が少なければそこまで気にならないのですが、今回のように数万ファイル規模のリポジトリになると、この積み重ねが無視できない待ち時間になってきます。
逆に言うと、WSL2のLinuxネイティブ側（ext4）で完結している分には、普通のLinux環境と変わらない速度が出ます。
遅いのは「Windows側のドライブをまたぐとき」だけです。
実際に引っ越した
数字を見てしまうと迷う理由もないので、リポジトリ本体を~/Programming/側に移動しました。
移動自体はcp -rで丸ごとコピーするだけですが、ファイル数が多いリポジトリだと/mnt/c側からの読み込みそのものが遅いため、コピー作業自体にもそれなりに時間がかかりました。
移行後は、Windows側のエクスプローラーからも次のパスでアクセスできます。
アクセス方法
1 | \\wsl.localhost\Ubuntu-24.04\home\ユーザー名\Programming\ |
普段の作業はWSL2側のターミナルやVS CodeのRemote-WSL接続から行い、Windows側からは必要なときだけこのパスで覗く、という運用に落ち着きました。
まとめ
体感の話でしか聞いたことがなかった「WSL2の/mnt/cは遅い」を実際に数字にしてみると、想像より大きな差でした。
ファイル数が多いリポジトリを日常的に触るなら、WSL2のネイティブファイルシステム側に置くほうが圧倒的に快適という結論になります。
以上となります。
計測してよかった（^^
それではお疲れさまでした。
