yNagaokaのブログ

このブログはNGS解析初心者がつまずいた部分と解決方法をまとめた覚書のようなものです。

WSLがストレージを異常に圧迫する問題を解決したときの覚書

はじめに

私はWindowsユーザーでWSLを利用しているのですが、最近PCが異常にフリーズするしデータ解析中にストレージ不足のエラーが頻発するようになりました。
色々な記事を参考にしてストレージを開放するために奮闘したのでその作業の覚書を残しておこうと思います。

状況確認

256GのLaptop PCを使っておりストレージの空き容量が1GBを下回っている状況です。WSL2にUbuntu20.04をインストールしておりDockerやSingularityCE、R、Python、関連ツールもインストールしています。初めにPCの設定画面からストレージの項目を開き、重いアプリケーションは何かを確認しました。一番はAdobe creative cloudでした。確かにPhotoshopIllustratorなど沢山インストールしていてバックアップも頻発に取るアプリなので納得なのですがそれでも数GBの範囲です。他に1GBを超えるようなものは見当たりません。また、ダウンロードやゴミ箱にあるファイルも全て消去済みです。

対策1:Dockerの整理

1) 使用容量の確認と不要なdocker imagesの消去

初めに以下のコマンドでどの項目が容量を圧迫しているのかを確認しました。

$ df -h

その結果、Dockerが最も容量を消費していたので整理することにしました。
次に以下のコマンドでDockerの何がどのくらい容量を消費しているのかを確認しました。
(以下の出力結果は整理後の状態です。整理前を残すのを忘れました。当時はImagesとBuild Cacheがかなりの容量を占めていました。)

$ docker system df
TYPE            TOTAL     ACTIVE    SIZE      RECLAIMABLE
Images          1         1         60.11GB   0B (0%)
Containers      2         0         0B        0B
Local Volumes   0         0         0B        0B
Build Cache     0         0         0B        0B

Imageが一番多く容量を消費していたので、あまり使用していないDocker imagesを合計で40G程度消去しました。

2) キャッシュのクリア

次にDocker imageをbuildする際に残るキャッシュ (Build Cache) も容量を圧迫していたので以下のコマンドで消去しました。

$ docker builder prune

再度使用容量を確認すると無事消去できていることが確認できました。

対策2:SingularityCEの整理

3) キャッシュのクリア

Docker imagesと比べてSingularity imageは半分以下のサイズであり、頻繁に使用しているのでSIF (Singularity image file)は消去したくない。なのでBuild時に残るキャッシュのみを消去しました。

$ singularity cache clean --all

こちらも無事消去できたので一旦PCを再起動し、設定画面からストレージを確認しました。50Gほどの空き容量ができていたので一先ず良しと思い作業を終了しました。
しかし、後日ストレージ不足のエラーが再度出現します。

対策3:DockerとDocker Desktopのアンインストール

4) Dockerストレージドライバーの確認

色々調べているとDockerのストレージドライバーが重くなっているのではないか?という記事を見つけたので確認してみました。
docker infoではバージョンやイメージの数などが色々出力されます。Storage Driverという項目を見つけて確認してください。

# Dockerストレージドライバーがどれかや諸々を確認したい場合  
$ docker info 
Storage Driver: overlay2

# 以下のコマンドだとストレージのみ確認できます。
$ docker info | grep "Storage Driver"

どうやらストレージはoverlay2のようです。

5) ストレージの容量の確認  

/var/lib/docker/overlay2はデフォルトの保存先です。

sudo df -h /var/lib/docker/overlay2
[sudo] password for ynagaoka:
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc        251G   51G  188G  22% /

容量を確認してみるとそこまで圧迫している感じではありません。しかし、Dockerが依然としてストレージを圧迫している状況なのでアンインストールも視野に入れることにしました。

6) Dockerアンインストール前の再確認

Dockerをアンインストールする前に最後の抵抗を試みました。以下のコマンドを実行し、imageやキャッシュ諸共全て消去しました。 このコマンドは他人がPullしたimageやBuild中のキャッシュなど全てを消し去るので、共通のPCやサーバーなどで実行しないように注意してください。 不安な場合はdocker system prune -hでコマンドの使い方を確認してください。

$ docker system prune -af

実行後、再起動しストレージを確認しましたが容量は回復しませんでした。
どうしたものかと悩みましたが、またダウンロードすればいい話なので一度DockerとDocker Desktopをアンインストールすることにしました。

7) Dockerのアンインストール

Dockerの古いバージョンがインストールされている可能性があったので以下のコマンドで消去しました。

$ sudo apt-get remove docker docker-engine docker.io containerd runc

apt-getを実行したときに、上のパッケージがインストールされていないと表示されれば OK です。

次に、以下のコマンドでDocker Engine、CLI、Containerd、Docker Compose パッケージをアンインストールします。

$ sudo apt-get purge docker-ce docker-ce-cli containerd.io docker-compose-plugin

ホスト上のImage、Container、Volume、カスタマイズした設定ファイルは自動的に削除されず/var/lib/docker/等に保持されるため以下のコマンドで消去します。

$ sudo rm -rf /var/lib/docker
$ sudo rm -rf /var/lib/containerd

Docker Desktopはアプリの項目から手動でアンインストールしました。
dockerと打ち込み、コマンドが無いというエラーが出ればアンインストール完了です。 再起動しストレージを確認しましたが、容量は空きませんでした。。。

対策3:WSL driversの圧縮

8) ext4.vhdxの圧縮

Dockerのアンインストール後、もう一度df -hで容量を調べたら今度は何故かWSLがストレージの大半を占めるようになっていました。

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
none            238G  237G   0G  99% /usr/lib/wsl/drivers

色々な記事を見た結果、原因は/usr/lib/wsl/driversなのでここにあるファイルを圧縮すればいいらしいという事が分かりました。
早速以下の手順で圧縮することにしました。(ここからはPowershellで行います。)

9) Powershellを起動し以下の手順でコマンドを実行する。

・WSLをシャットダウン

$ wsl --shutdown

UbuntuのPATHを確認

$ ls $HOME\AppData\Local\Packages\
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2023/10/16     12:03                CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc

上のコマンドの出力結果からUbuntuと名の付くファイルを探します。 私の場合はCanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgscでした。
・該当ディレクトリーに移動して中身の確認

$ cd $HOME\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc
$ ls 
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
d-----        2022/09/29      9:51         LocalState
$ cd LocalState
$ ls
Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a----        2024/03/08     14:13   165451661312 ext4.vhdx

ext4.vhdxが今回の圧縮対象のファイルです。

・diskpartを起動(ここからの操作はdiskpartで行う)

$ diskpart

・該当ファイルを選択

DISKPART> select vdisk file=C:\Users\nagao\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu20.04onWindows_79rhkp1fndgsc\LocalState\ext4.vhdx
DiskPart により、仮想ディスク ファイルが選択されました。#これが表示されればOK

・attach

DISKPART> attach vdisk readonly
 
100% 完了しました
DiskPart により、仮想ディスク ファイルがアタッチされました。 #このログでOK

・圧縮

DISKPART> compact vdisk

100% 完了しました

DiskPart により、仮想ディスク ファイルは正常に圧縮されました。

・Detach

DISKPART> detach vdisk
DiskPart により、仮想ディスク ファイルがデタッチされました。

・完了

DISKPART> exit

・圧縮されているかUbuntuを起動して確認

$ df -h
Filesystem      Size  Used Avail Use% Mounted on
none            238G  180G   58G  76% /usr/lib/wsl/drivers

なんと58Gも圧縮できていて、その分のPCストレージが回復しました!
今回はストレージを圧迫していたDockerを消去したら、今度はext4.vhdxが容量を圧迫し始めるという現象でしたが無事に解決することができました。