WSL1 vs WSL2：同じペンギン、天と地のディスク占有

二つのアーキテクチャ、二つのストレージモデル

WSL1にはLinuxカーネルがそもそもない。LinuxのシステムコールをリアルタイムでWindowsの呼び出しに翻訳し、ファイルは普通のフォルダー — 歴史的には%LOCALAPPDATA%\Packages\<Distro>\LocalState\rootfs — に置かれ、Windowsのツールから完全に見える。そのためディスク的には軽く、スクリプトが/mnt/c上のファイルを触るときは速い。ただし翻訳は不完全で、Dockerもsystemdも特殊なsyscallが必要なものも動かない。WSL2は軽量なユーティリティVMで本物のLinuxカーネルを動かし、互換性は解決する — しかしディストリビューションのファイルシステム全体がext4.vhdxの中に住むことになる。Windowsがマウントするが解釈しない、仮想ディスクイメージだ。

vhdxはStoreインストールのディストリビューションなら%LOCALAPPDATA%\Packagesの下、最近のインストールなら%LOCALAPPDATA%\wslの下に置かれ、ひとつ厄介な性質を持つ。要求に応じて増え、自分で縮むことはない。ディストリビューション内でファイルを削除しても仮想ディスク内の空きは増えるが、.vhdxファイルは上限水位をキープしたままで、自分でコンパクトにしない限り下がらない。ディストリビューション内で大掃除した直後にエクスプローラーでファイルサイズを確認するのが古典的な失望だ。数値は動いていない。

それぞれがギガバイトを隠す場所

どちらのバージョンも後片付けをせず、容量は驚くほど少ない場所に消えていく：

• WSL2のext4.vhdx — ディストリビューションごとに1つ。Docker中心の開発環境なら日常的に30GB超になる
• Docker Desktop自身のデータディスク（docker_data.vhdx）— 同じ「増えるだけ」ルールに従う
• WSL1のrootfsフォルダー — 比べれば控えめだが、放置された古いディストリビューションはインストール一式を保持し続ける
• ディストリビューション内のLinuxパッケージとビルドのキャッシュ — aptキャッシュ、node_modules、target/、ビルドフォルダーがvhdxを恒久的に膨らませる
• ダウンロードに置き去りにされて忘れられたwsl --exportのバックアップと落としたディストリビューションイメージ

ディストリビューションを壊さずに容量を取り戻す

まず内側から掃除する。apt autoremoveとapt clean、Docker Desktopでのdocker system prune、npmとpipのキャッシュ破棄 — 容器を縮める前に仮想ディスクの中身を空にするものなら何でも。次にwsl --shutdown。稼働中のディストリビューションは自分のvhdxをロックするからだ。それからイメージをコンパクトにする。Hyper-Vツールがあるなら-Mode Fullオプション付きのOptimize-VHD、どのWindowsでも使えるのはdiskpartのselect vdisk file="<path>", attach vdisk, compact vdisk, detach vdisk。最近のWSLにはwsl --manage <Distro> --set-sparse trueがあり、vhdxが自動で容量を手放せるようになる — 長期的には文句なしに優れた設定だ。

最後の手段がふたつ、その名に値する。wsl --exportはディストリビューションを.tarに梱包し、wsl --importで別ドライブに持ち込める — 満杯のC:からWSL2インストールを移す正攻法だ。そしてwsl --unregister <Distro>はディストリビューションとvhdxを完全に削除する。このコマンドにアンドゥはない。核弾頭として扱うこと。ついでに.wslconfigファイルでメモリとプロセッサを制限してVMの食欲に蓋をしよう。さもないとアイドル中のWSL2 VMは、何のためでもなく数GBのRAMを握り続ける。

よくある質問

次に読む記事