WSL2上でcodex cliとPodmanを動かして複数開発を行っていますが、codex cli専用のWSL2環境が700GB以上に肥大化し、開発用PCのシステムドライブ（1TB SSD）が逼迫したため、新たに2TBのM.2 SSD（KIOXIA EXCERIA PLUS G3）を増設しました。
せっかくなので、単なる容量拡張ではなく、Windows 11の機能である**Dev Drive（開発者ドライブ / ReFS形式）**を構築して計測を行いました。本記事では、ReFSとNTFSのI/Oパフォーマンス比較、大容量WSL環境の移行プロセス、および遭遇したエラーの回避手順を共有します。
1. ドライブ構成とDev Driveの導入
増設した2TBのSSDは、開発ワークロードと通常のデータ保存で特性が異なるため、2つのパーティションに分割しました。
- Dドライブ (Dev Drive / ReFS): 1TB。WSL2仮想ディスク、Gitリポジトリ、パッケージキャッシュ用。アロケーションユニットサイズは4096バイト。
- Eドライブ (NTFS): 約1TB。一般的なドキュメント、アーカイブファイル、その他アプリ用。
Dev Driveはファイルシステムレベルで開発タスクに最適化されており、Microsoft Defenderの「パフォーマンスモード」による非同期スキャンと組み合わせることで、ビルドやパッケージインストールのI/Oレイテンシ低下が期待できます。
2. ストレージI/Oパフォーマンスの比較（NTFS vs Dev Drive）
移行作業に先立ち、CrystalDiskMarkおよびPowerShellスクリプトを用いて、新旧ドライブとファイルシステム間の性能差を検証しました。
2.1 CrystalDiskMarkによる基礎ベンチマーク
| ドライブ | ファイルシステム | 用途 | SEQ1M Read | SEQ1M Write | RND4K Read | RND4K Write |
|---|---|---|---|---|---|---|
| C: (標準 1TB) | NTFS | システム | 4894 MB/s | 1230 MB/s | 52.67 MB/s | 208.97 MB/s |
| D: (新規 2TB) | ReFS (Dev) | 開発領域 | 5030 MB/s | 3948 MB/s | 52.72 MB/s | 237.27 MB/s |
| E: (新規 2TB) | NTFS | データ領域 | 5028 MB/s | 3945 MB/s | 51.18 MB/s | 234.13 MB/s |
考察: 新規SSDはシーケンシャルWriteで約4GB/sを出力していますが、逼迫したCドライブは1.2GB/sまで落ち込んでいました。SSDの空き容量不足による書き込み性能の低下が顕著に表れています。
2.2 PowerShellによる実用プロファイル比較
CrystalDiskMarkではReFSの特長を評価しきれないため、実務を想定したI/OスクリプトでDドライブ（ReFS）とEドライブ（NTFS）を比較しました。
# 1. 2GBのダミーファイルを作成し、複製時間を計測
$largeCopyTime = Measure-Command { Copy-Item $largeSource $largeDest }
# 2. 1000個の小ファイルを連続作成し、完了時間を計測
$smallFileTime = Measure-Command {
for ($i = 1; $i -le 1000; $i++) { "test" | Out-File -FilePath "$($smallPath)\file_$($i).txt"}
}
【計測結果】
| タスク | D: (ReFS / Dev Drive) | E: (NTFS) |
|---|---|---|
| 2GBファイルの複製 | 16.25 ms | 587.82 ms |
| 小ファイル1000個の作成 | 384.40 ms | 313.16 ms |
考察: ReFSのBlock Cloning機能により、同一ボリューム内でのファイル複製がメタデータの操作のみで完結するため、ギガバイト級のコピーがミリ秒オーダーで終了しています。一方で、単発の小ファイル作成の連続タスクにおいては、整合性担保のオーバーヘッドからかNTFSがわずかに優位な結果となりました。
3. 大容量WSL2環境の移行プロセス
既存のUbuntu環境をエクスポートし、新規作成したDev Driveへインポートします。
3.1 エクスポート時のソケットエラー
wsl --shutdown
wsl --export CodexUbuntu D:\CodexUbuntu.tar
実行中、以下のような pax format cannot archive sockets エラーが大量に出力されました。
./home/devuser/.gnupg/S.gpg-agent: pax format cannot archive sockets
./home/devuser/.local/share/containers/storage/.../attach: pax format cannot archive sockets
対応: gpg-agentやPodmanなどのUnixドメインソケットはtarにアーカイブできませんが、これらはプロセス起動時に再生成される一時ファイルであるため、エラーは無視してエクスポートを続行可能です。
3.2 容量計算の罠と Input/output error
エクスポートされた .tar ファイルのサイズが約724GBに達しました。これをそのままDドライブ（残り容量約200GB）にインポートしようとしたところ、当然ながらディスクフルとなり Input/output error で失敗しました。
対応: インポート元となる .tar ファイルを一時的にEドライブ（NTFS）へ退避させ、Dドライブの空き容量を確保した上で再実行しました。
# E: に退避したtarファイルを、D: へインポート
New-Item -ItemType Directory -Path "D:\WSL\CodexUbuntu"
wsl --import CodexUbuntu_New D:\WSL\CodexUbuntu E:\CodexUbuntu.tar
4. 移行後の環境セットアップ
インポート完了後、元の環境と同等に利用するための設定を行います。
4.1 デフォルトユーザーの再設定
インポート直後は root でログインされるため、wsl.conf を編集して標準ユーザーを指定します。
# WSL内で実行
sudo tee /etc/wsl.conf <<EOF
[user]
default=devuser
EOF
設定後、Windows側から wsl --terminate CodexUbuntu_New を実行して再起動させます。
4.2 I/Oパスの最適化（開始ディレクトリの変更）
Windows TerminalからWSLを起動した際、カレントディレクトリがWindowsのプロファイルパス（/mnt/c/Users/...）になっていると、9Pプロトコル経由のアクセスとなりDev DriveのI/O性能を活かせません。
Terminalのプロファイル設定から「開始ディレクトリ」を以下のように変更し、起動時からWSLネイティブのファイルシステム（/home/...）を参照するようにします。
\\wsl.localhost\CodexUbuntu_New\home\devuser
4.3 レジストリ編集によるディストリビューション名の修正
再インポートの手間を省くため、レジストリからWSLの管理名を直接変更します。
- 古い環境を削除: wsl --unregister CodexUbuntu（※これによりCドライブの容量が解放されます）
- regedit を起動。
- HKCU\Software\Microsoft\Windows\CurrentVersion\Lxss 配下の該当GUIDを検索。
- DistributionName キーの値を CodexUbuntu_New から CodexUbuntu に変更。
まとめ
本対応により、システムドライブの容量枯渇というクリティカルな課題を解決するとともに、Dev Drive (ReFS) の導入によって開発環境のI/O特性を改善することができました。特にBlock Cloningによる複製の高速化は、大規模なリポジトリ操作やコンテナビルドにおいて明確なアドバンテージとなります。
WSL2の仮想ディスク肥大化に対応する際の一助となれば幸いです。