WSL2 プロジェクトを Windows ドライブに置くとパフォーマンスが低下します。その理由は次のとおりです。

Sophia Chen included in Programming Homelab Windows Linux

2026-04-11 255 words 2 minutes

Contents

<本文>

Linux 用 Windows サブシステムを初めて使用し始めると、すべてが機能しているように見えます。リポジトリのクローンを作成し、依存関係をインストールし、アプリを実行し、「Windows 上の Linux」ができたと自分自身に納得させることさえできます。その後、何か違和感を感じ、すぐに実行できるはずのコマンドにかなりの時間がかかることに気づきます。パッケージのインストールは長引き、ファイルウォッチャーは異常な動作をし、開発サーバーは単一の原因とは考えにくいほど遅く感じられます。最初は、これが明らかな原因であるため、WSL2 自体のせいにされますが、通常は間違っています。

本当の問題はファイルがどこに存在するかです

Windows ファイルシステムは隠れたパフォーマンス上のペナルティをもたらします

プロジェクトが次のような場所にある場合:


/mnt/c/Users/YourName/projects/my-app

実際に Linux ファイルシステムを操作しているわけではありません。あなたは Windows ファイルシステムで作業しており、翻訳層を通じてアクセスします。

この詳細は見落とされやすく、驚くほど高価です。 WSL2 は、軽量の仮想マシン内で実際の Linux カーネルを実行します。その環境内には、ネイティブ Linux ファイルシステムがあります。高速で一貫性があり、Linux ツールが期待するとおりに動作します。

ただし、 /mnt/c 、 /mnt/d 、またはマウントされた Windows ドライブにあるファイルにアクセスする場合、すべてのファイル操作は Linux と Windows の間の境界を越える必要があります。その境界は、パフォーマンスが低下する場所です (エラーをスローすることなく静かに、これにより悪化します)。

WSL は優れていますが、Windows に戻るにはまだ十分ではありません

Copilot を我慢できるようになるには、仮想 Linux マシン以上のものが必要です。

これが実際に速度を低下させる理由

ファイルの多いワークフローにより、ファイルシステムの変換のオーバーヘッドが増大する

最新の開発ワークフローは、ファイルが非常に重いです。次のようなものを実行すると何が起こるかを考えてください。


npm installpip installcargo buildnpm run dev

これらのツールは、何千もの小さなファイルを作成、読み取り、変更します。これらは、ファイルシステムへの高速アクセスと予測可能な動作に依存しています。

ネイティブ Linux ファイルシステムでは、これは最適化されますが、WSL2 を介してアクセスされる Windows ファイルシステムでは、これらの操作のそれぞれに 2 つの異なるシステム間の変換が含まれます。

その結果、物事はうまくいきますが、すべてが遅くなるだけです。場合によっては 2 倍、場合によっては 10 倍、さらに場合によってはさらに悪化することもあります。速度低下は多くの小規模な操作に分散しているため、必ずしもすぐに気づくわけではありませんが、時間の経過とともに増加していきます。

この問題を観察する最も簡単な方法の 1 つは、Git を使用することです。 /mnt/c に保存されている大きなリポジトリで git status または git checkout を実行し、Linux ホームディレクトリ内の同じリポジトリと比較します。

実際に不正行為のように感じられる 5 つの Git 機能

Git のこれらの隠れたコーナーは時間を節約し、ワークフローの苦痛を軽減します。

Git は多くのファイルシステム操作を実行するため、違いは微妙ではありません。ディレクトリをスキャンし、メタデータをチェックし、ファイルの状態を比較します。遅いファイルシステムブリッジでは、これは痛ましいほど明らかです。人々は、Git 自体を非難したり、リポジトリが「ただ大きいだけ」だと考えたりすることがよくあります。実際には、ファイルシステムの選択がほとんどの損害を引き起こしています。

もう 1 つの一般的な症状は、ファイル監視の信頼性が低いことです。 webpack、Vite、nodemon などのツールは、ファイルシステムイベントに依存して変更を検出します。ネイティブ Linux ファイルシステムでは、これらのイベントは効率的に配信されます。

Windows の境界を越えると、矛盾が生じます。

次のような内容が表示される場合があります。

変更がリビルドをトリガーしない
リロードの遅延
ポーリングフォールバックによる CPU 使用率の増加

これはツールのバグではなく、Windows と Linux の間でファイルシステム通知が変換される方法の結果です。プロジェクトを WSL2 のファイルシステムに移動すると、これらの問題は解消される傾向があります。

Crucial Pro オーバークロック DDR5 RAM 32GB (2x16GB) 6000MHz CL36

ブランド

重要な

テクノロジー

DDR5

/mnt/c の誤解を招く利便性

利便性によりクロスシステムアクセスのコストが隠れる

人々がここに行き着く理由は完全に理解できます。 Windows で起動すると、ファイルとエディタがそこにあります。 WSL2 から /mnt/c 経由でアクセスするのが自然です。

これにより、統一された環境のような錯覚が得られます。 1 つのファイルシステム。Windows と Linux の両方からアクセスできますが、統合されておらずブリッジされており、ブリッジにはコストがかかります。

この設定は、たまにファイルにアクセスする場合には問題ありませんが、高頻度のファイルシステム操作に依存するアクティブな開発ワークロードには適していません。

WSL2 内で Linux ファイルシステムを操作すると、違いがすぐにわかります。パスは次のようになります。

これで、完全に Linux 環境内で動作するようになり、変換層や OS 間のオーバーヘッドは発生しません。このディレクトリ内で依存関係のインストールを試してみると、インストールがより速く完了し、開発サーバーもより速く起動し、確実にリロードされることがわかります。

しかし、Windows からのアクセスはどうなるでしょうか?

まだ /mnt/c を使用する可能性がある場合

一部のワークロードは依然として Windows ファイルシステムの恩恵を受けています

公平を期すために言うと、この状況では Windows ファイルシステムが役に立たないわけではありません。ドキュメントやメディアファイルへのアクセス、環境間での単純なスクリプトの共有、Windows 専用ツールとの相互運用性などの有効な使用例がありますが、アクティブな開発、特に大規模な依存関係ツリーや頻繁なファイル操作を伴う開発の場合、プロジェクトを置く場所としては間違っています。 WSL2 を「Windows 内の Linux」ではなく、Windows とうまく統合できる別個の Linux システムとして考えると役立ちます。

そのモデルを採用すると、ファイルシステムの決定が明確になります。通常、ネットワークにマウントされたファイルシステム上で待ち時間の長い Linux プロジェクトを開発することはありません。それをローカルに保持することになります。 WSL2 では、Linux ファイルシステムはローカル環境であり、Windows ファイルシステムは Linux の観点から事実上リモートです。

修正には数分かかります

Linux ファイルシステム内でプロジェクトまたはクローンを移動する

解決策は複雑ではありません。プロジェクトを移動するだけです。


mv /mnt/c/Users/YourName/projects/my-app ~/projects/

または、WSL2 内で直接再作成します。


git clone <repo>

~/projects/my-app

エディタを更新して新しい場所を開きます。

パフォーマンスはチューニングよりも場所に依存します

WSL2 は、独自の内部境界が尊重された完全な Linux 環境として扱われる場合に最適に機能します。プロジェクトがそのスペース内に存在する瞬間、ハイブリッドワークフローに伴う摩擦のほとんどは消えます。 Windows は依然としてインターフェイス層として有用ですが、実行コンテキストは再び一貫性を持ち、ツールは設計どおりに動作します。

興味深いのは、その状態に到達するために必要な努力がどれほど少ないかということです。場所を変更すると、これまでのほとんどの構成チューニングよりもパフォーマンスが変化します。それが直感的に理解できるようになると、以前の動作は謎ではなく、継続的な往復アクセス用に最適化されていなかったシステムを横断した結果として予測可能な結果のように見え始めます。

*️⃣ 出典リンク:

ファイルシステム、 WSL は優れていますが、Windows に戻るにはまだ十分ではありません、実際に不正行為をしていると感じる 5 つの Git 機能、 webpack、リモート WSL 拡張機能、