Windowsの容量がかなり減っており、対応が必要になってきたのであれこれしていたメモ
原因を調べる
結構これは自明で、WSL2 のストレージに問題があった。 これが現在約 200 GB ほどあり、削減しないといけない状態でした。
この3年くらいいろいろなデータを処理したり、でかいデータを手元で持って改善したりしていたため、容量が大きくなっていったのは仕方がない部分があります。
WSL2 のストレージを削減する
WSL2のストレージを削減する場合、Windows11 Proの場合は optimize-vhd
コマンドが動作しますが、私は Windows11 Home なので動作しません。
代わりのコマンドですが、調べていくと下記の issue へのリンクが多数見つかったので、こちらを試しました。
(情報源として一番まとまっていたのは下記のページでした) https://scrapbox.io/miyamonz/Windows10_Home%E3%81%A7vhd%E3%82%92%E5%9C%A7%E7%B8%AE%E3%81%99%E3%82%8B
WSL2 を停止して、 diskpart を起動し、 compact をするのですが… これを実行しても特に容量が減りませんでした。もしかするとバージョン違いの開発環境や、そもそも過去に引っ張ってきたデータの残骸などいろいろ考えられるため、単純な方法ではうまくいきそうにありません。
WSL2 のバックアップを取る
WSL2 のバックアップを取ろうと考え、外付けのSSDにコピーすることを思いつきました。
WSL2 から別のディスクにアクセスするのは簡単にできました( cd /mnt/e/
で普通に入れた)
ここから rsync コマンドで home ディレクトリ配下をコピーしていったのですが…
rsync -av --progress . /mnt/e/ubuntu_backup
実行中にやたら容量が膨れていき、外付けのSSDのストレージ領域を食切る勢いでした。
原因は次の2つです。
- 外付けSSDのフォーマットが exFAT で、アセットアロケーションサイズが大きかった
- そもそもホームディレクトリ配下に大量のファイルがあり、容量総計が 100GB を超えている
それぞれについて対応を考えます。
外付けSSDのフォーマットが exFAT で、アセットアロケーションサイズが大きい問題への対策
なぜこれが起きるのか? については下記のリンクが参考になります。 ファイルやフォルダの【サイズ】と【ディスク上のサイズ】が違うのはなぜ? - MiniTool Partition Wizard
アセットアロケーションサイズに物理的な最低サイズは引っ張られるわけです。 今回、もともと外付け SSD にはバイナリデータだけを置く想定だったので、それまでアセットアロケーションサイズが大きくても問題なかったのですが、今回のようにファイルを大量に置くケースとは相性が悪い状態でした。
なので、アセットアロケーションサイズを小さくするため一度全データを移動し、フォーマットしなおしました。 (フォーマットは NTFS にする案もありましたが、どの OS とつなぐかわからないのでいったん exFAT を維持することにしました)
この際に tar にして zstd で圧縮して、とやっていたのですが、 zstd の --ultra
による圧縮がうまく行きませんでした(なぜかエラーになる)。
なので諦めて圧縮レベルはそのままにしました(デフォルトから少し上げてみるのはよかったかもしれない)。
外付け SSD に保存されているデータは結構な量あったので、ついでに Windows で最近起動していないアプリケーションを削除しました。 (主にゲーム系)
ホームディレクトリ配下に大量のファイルがあり、容量総計が 100GB を超えている問題への対策
これは asdf に保存されているバージョンを減らし、バックアップを取るデータを限定することで対応しました。 下記の shell スクリプトを書きました。 GitHub Copilot に聞きつつ書きました。
#!/bin/bash # 実際はもっといっぱいあります target_dirs=(".aws" ".config" "Documents" "work") rsync_target="/mnt/e/ubuntu_backup/" for target_dir in "${target_dirs[@]}"; do # ディレクトリのコピー find "$target_dir" -type f -print0 | parallel -0 rsync -R --stats {} "$rsync_target" done # 直下のファイルのコピー find . -maxdepth 1 -name '.*' -type f -print0 | parallel -0 rsync -R --stats {} "$rsync_target" find . -maxdepth 1 -type f -print0 | parallel -0 rsync -R --stats {} "$rsync_target"
しかし絞ったといえ結構なサイズがあり、実際にコピーを試してみるとすごい時間がかかりました。 今後考えていることとしてはやっぱり tar にまとめ切って、圧縮して置くかなーという感じです(そのままファイルが見れたほうが楽ではあるが、そもそもコピーが終わらないのはきついので)
あとそもそもこの方法だと git リポジトリが結構心配で、git のオブジェクトファイルごとにストレージが確保されると結構な容量になることが予想されます。 そういう意味でもファイルをまとめて圧縮が固いかな… という気持ちです。
それと今環境を作り直すと ISUCON に影響出てしまいそうなので、これは12月以降に考えようかと思います。
追加の対策
2.5 インチのSSDを追加して NTFS でフォーマットし、そちらにバックアップをとるのも考えています。 これもそのうち買うかな~位のノリです。
それとストレージ周りの設定をもう一度見直したいですかね。 そろそろ Ubuntu-22.04 に移行したいので、バックアップを取ったらそっちにコピーする気でいるのですが、その前に調べてセットアップ時に実行しておきたいです。
まとめ
WSL2 が油断すると容量がすぐ膨れるので日々モニタリングしておかなければとなりました。 この対応によってストレージについて少しだけ理解できた部分もあり、単純にストレージ増やす方向にいかず考えてみて良い勉強になりました。