- Windows NTのサブシステム構造は、他のOS向けプログラムを実行するための API呼び出し変換層として構成されてきた
- WSL1はこの流れを受け継ぎ、Linux呼び出しをWindowsカーネル呼び出しへ変換する軽量な変換層として動作する
- WSL2は性能問題を解決するため、Hyper-Vベースの完全なLinux VMへ移行し、実際のLinuxカーネルを実行する
- WSL2は動的メモリ管理、Windowsドライブのマウント、WSLgによるGUI統合などにより、一般的なVMより高い統合性を提供する
- ファイル管理の不便さやディスクイメージ依存性などの制約はあるが、WSL1とWSL2の長所と短所を状況に応じて使い分けられる柔軟性が重要
Windows NTのサブシステム概念
- Windows NTのサブシステム(subsystem) は、他のOS用プログラムを実行するためのAPIセットと呼び出し変換層を意味する
- 過去のNTにはOS/2サブシステム(OS2SS.EXE)、POSIXサブシステム(PSXSS.EXE) などが存在した
- CSRSS.EXEはWin32 API変換層で、一部の機能はカーネルモード（
WIN32K.SYS）へ移動した
- POSIXサブシステムは政府認証向けの最小実装レベルであり、後にInterixベースのWindows Services for Unixへ置き換えられた
WSL1: 翻訳ベースのLinux層
- WSL1(Windows Subsystem for Linux) はLinuxシステムコールをWindowsコールへ変換する薄い翻訳層として動作する
- 起動時、
bashプロセスは数MBのメモリしか使用せず、タスクマネージャーでは通常のプロセスとして表示される
- ルートファイルシステムはNTFS上の個別ファイル構造として存在し、ストレージのオーバーヘッドがほぼない
- 制限事項
- I/O性能低下: LinuxとWin32ファイルシステムAPIの違いによる変換コスト
- GUI実行時に外部Xサーバーが必要（例: X410）
- Rawソケット非対応のため、
traceroute、nmap、tcpdumpなどが実行できない
WSL2: Hyper-VベースのLinux VM
- 利用者の要望に応じて、MicrosoftはHyper-V上で動作する完全なLinux VMを導入した
- ルートファイルシステムは単一のVHDXファイルで管理される
- コマンド
wsl --set-version "Ubuntu" 2でWSL1↔WSL2間の変換が可能
- 性能特性
- 初回起動は遅いが、ネイティブLinuxカーネルを実行する
- メモリ使用量は動的で、最大物理メモリの半分まで拡張可能
stressテスト結果、メモリ使用量は負荷に応じて増加後、自動的に縮小する- 必要に応じて
wsl --shutdownコマンドでVMを終了可能
WSL2の統合機能と制限
- WSL2は伝統的なVMとは異なり、Windowsとの統合性を強化
- Windowsドライブの自動マウント、Linuxドライブを
\\wsl$\\パスでアクセス、WSLgを通じたGUIアプリ実行
- GUIアプリはRemote Desktop Protocol（RDP）でストリーミングされ、DPIやテキストスケーリングは別途設定が必要
- ファイル管理の問題
- Linuxの作業データは
ext4.vhdxイメージ内に保存され、可搬性と復旧リスクがある
wsl --unregister Distro実行時、すべてのデータが即時削除される- Windowsドライブ（
/mnt/c）を使用する場合、NTFS＋VMオーバーヘッドによる性能低下
- ファイルシステムプロトコル
- WSL1は
drvfs、WSL2はPlan9の9pプロトコルを使用
- 変換の過程で
drvfs由来のバグ残存例が言及される
- 代替策
- 別途VHDXイメージを作成し、
wsl --mount --vhdでマウントして作業データを分離することを推奨
.wslconfigで自動設定はできず、スクリプトで処理が必要
結論
- Windows NTのモジュール型設計と安定したカーネルABIは、旧世代のドライバー互換性を維持する
- WSL1は低メモリ使用が長所で、WSL2は実際のLinuxカーネルによってより高い互換性と性能を提供する
- WSL2はVMの欠点を最小化し、ホストOSとの統合を強化した構造
- 伝統的な定義ではVMに近いが、軽量な統合型環境として「サブシステム」と呼ぶ価値がある
3件のコメント
わあ、開発者のスッキもいるね
Hacker Newsのコメント
WSL2はHyper-Vのサブセット上で動作しており、基本的にはハイパーバイザー上のVMです
ただし、一般的なHyper-V VMとは異なる点があります。たとえば、WSL2のLinuxディストリビューションはGPUパーティショニング（つまりPCI/GPUパススルー）とDirectXの特殊な実装により、XやWayland環境でもGPUアクセラレーションを利用できます
こうした機能はPowerShellなどを使ったハックで通常のHyper-Vでも可能ですが、公式にはWindows Serverでのみサポートされています
ただし、「XやWaylandがレンダリングを担っている」というのは誤解です。実際にGPUを使うのはアプリケーション自体で、X/Waylandはレンダリング後のウィンドウ合成程度を担当しているだけです
色変換のような複雑な処理もありますが、計算量は少なめです
WSL1はpico processベースで、Drawbridge研究から派生した技術です
関連動画 The Linux Kernel Hidden Inside Windows 10 と WSL Pico Process Overview を参照してください
同じDrawbridge技術は、SQL ServerをLinux上で動かす際にも使われています
詳しくは Ars Technicaの記事 に載っています
WSL2へ移行した理由は理解できますが、WSL1の開発を完全に中止したのは残念です
私たちのCI環境はほとんどがLinuxベースですが、一部のツールチェーンはWineではうまく動きません（MSVCなど）
そのため、Windows上でLinuxビルドを円滑に実行できる環境が必要でした。WSL1ではこれが可能でしたが、WSL2はプロセス名前空間やファイルディスクリプタを共有しないため、さまざまな回避策が必要になります
IO速度は速くなりましたが、ファイル共有が遅いため実運用には不向きです
/mnt/cを通じてWindowsファイルにアクセスできます以前、Python C拡張モジュールをこの方法でビルドしたことがあります
WSL2はWindows環境と非常に密接に統合されたVMです
会社のポリシーでWindowsを使わなければならないため、開発用として毎日使っていますが、ほとんどの場合かなり快適です
ただ、RHEL8ベースなのでDebian系しかサポートされていないのが不便です。最近のグラフィカルアプリ対応がどうなっているのか気になります
psやtopではVMのプロセスしか見えません。docker run -it ubuntuでも似たようなことはできますが、何が違うのか気になります。個人的には分離された作業空間があまりにも不便でした
WSL2は結局軽量VMです。Firecrackerに近い概念で、高速起動と低メモリ使用量を目指しています
ただしDockerを複数動かすとメモリ要求は大きくなります。快適に使うには最低20GB以上は必要です
個人的にはWSL1のほうがはるかに有用です。C++と.NETのツールチェーン、ssh/scpなど、ほとんどのCLIツールが問題なく動作します
一方でWSL2はほとんど役に立ちません。Linux VMが必要ならVMwareを使います
VMwareはスナップショットツリー、3Dアクセラレーション、USBデバイス接続、仮想ネットワーク構成など機能が豊富で、GUIも便利です
WSL内部のVMディスクには
\\wsl$パスでアクセスできます古いソフトウェアがUNCパスをサポートしていない場合は、ドライブ文字にマッピングして対処できます
VHDXファイルが増え続ける問題があります。手動で**圧縮(compact)**しなければなりません
systemd-trimサービスで一部は解決できます関連Issueは GitHub WSL #12103 を参照してください
それでもだめなら、手動最適化方法 を使えます
ちなみにWSLはデフォルトでWindowsファイアウォール規則を迂回します。なぜMicrosoftがこのように設計したのか疑問です
実際のext4パーティションをマウントして、イメージファイルベースのブロックデバイスシミュレーションによる性能低下を減らせるのか気になります
WSL2 を頻繁に使うようになるにつれて、だんだん Linux を使う機会が減ってきたころ、これも EEE なのか？ という考えが頭をよぎります。
EEE - 取り込み、拡張、駆逐(Embrace, Extend, and Extinguish)