ディスク容量はどこへ消えたか: 分析とクリーンアップ

「ディスクがほぼ満杯」は、どんな Ubuntu ユーザーにもいつか起こります。厄介なのは、df は満杯だと教えてくれても、何が埋めたのかは教えてくれないことです。ここでは再現可能な順序、つまりまず特定してからクリーンアップする手順を説明します。

ステップ 1: 実際どれくらい埋まっているのか


df -h

Use% の列を見てください。主に見るのは / (ルートファイルシステム) と、/home が別パーティションなら /home です。

グラフィカルに確認するなら、ディスクでパーティションを選択したときの使用量バー、またはファイルマネージャーのサイドバー下部にある容量バーを見てください。

ステップ 2: 大きいディレクトリを見つける

du でも計算できますが、1 階層ずつ推測しながらたどることになります:


# Size of each subdirectory here, largest first
du -h --max-depth=1 . | sort -hr | head

ディスク使用量アナライザー (baobab) はツリー全体を一度にスキャンするので、こちらのほうがはるかに読みやすくなります:


sudo apt install baobab
baobab /home/$USER

指定したパスのスキャンが始まり、完了すると次のように表示されます:

Disk Usage Analyzer showing a folder list where snap takes 87.29 percent and 113.9 MB and .cache 12.13 percent, next to a rings chart with 130.5 MB in the centre and Rings Chart / Treemap Chart tabs — Disk Usage Analyzer: a sorted list with percentages on the left, the ring chart on the right, and any ring can be clicked to drill down

読み方:

左側のリストはサイズ順に並んでいます。行を 1 つずつ展開していけば正確なパスが分かるので、リングをクリックするより確実です
右下のツリーマップチャートは比率を面積に変えるので、最大のブロックが一目で分かります
このスクリーンショットはインストール直後の VM で、snap だけで 87% を占めています。バグではありません。Snap アプリはどれも複数のリビジョンを保持しています

Tip

~ のスキャンは数秒で終わり、/ のスキャンはシステム全体を走査するため数分かかります。まず ~ から始め、それでも使用量を説明できない場合にだけ / をスキャンしてください。

ステップ 3: 定番の容量消費元をクリーンアップする

古い Snap リビジョン

Snap はロールバックできるように直近のいくつかのリビジョンを保持し、そのそれぞれがプログラム全体のコピーです。これが先ほどの 87% の正体です。


# Keep 2 revisions instead of the default 3
sudo snap set system refresh.retain=2
 
# Remove every disabled revision
sudo snap list --all | awk '/disabled/{print $1, $3}' | while read name rev; do
  sudo snap remove "$name" --revision="$rev"
done

ダウンロードしたパッケージ


# Empty /var/cache/apt/archives
sudo apt clean
 
# Drop dependencies nothing needs any more
sudo apt autoremove --purge

systemd ジャーナル

journalctl のログは数 GB まで膨らむことがあります:


# Keep at most 200 MB
sudo journalctl --vacuum-size=200M
 
# Or keep only 7 days
sudo journalctl --vacuum-time=7d

ユーザーキャッシュ

ブラウザー、サムネイル、アプリのキャッシュはいずれも ~/.cache にあります:


du -h --max-depth=1 ~/.cache | sort -hr | head

削除する前に考えてください。ブラウザーのキャッシュは必要に応じて再生成され、通常はログイン状態も維持されますが、~/.cache/thumbnails はいつ削除しても安全です。

ステップ 4: 掃除だけでは足りないとき

クリーンアップで得られるのは時間だけです。本当に容量を確保するには、ディスクを大きくするか、データを移す必要があります:

仮想マシン: VM の設定で仮想ディスクを拡張し、その後パーティションを拡張します (growpart と resize2fs)
物理マシン: ディスクを追加してフォーマット・マウントします。詳しくはディスク、マウント、fstab を参照してください
データの移動: ~/Downloads や Docker のデータルートなど大きなディレクトリを新しいディスクへ移し、fstab でマウントします

FAQ

`df` は満杯と言うのに `du` の合計ははるかに少ない

よくあるのは、ファイルは削除されたのにプロセスがまだ開いているケースで、そのプロセスが終了するまで容量は解放されません。


# Find deleted files that are still open
sudo lsof +L1 2>/dev/null | head

通常の原因は動作し続けているログ書き込みプロセスです。それを所有するサービスを再起動してください (sudo systemctl restart <service>)。

「デバイスに空き容量がありません」と出るのに `df` は空きを示す

おそらく inode の枯渇 です。小さなファイルが大量にある場合 (メールスプール、コンテナーレイヤーなど) に典型的です。


# Check inode usage
df -i

IUse% が 100% ならこれが原因です。対処は同じ種類のクリーンアップですが、削除する必要があるのは大きなファイルではなく大量の小さなファイルである点が異なります。

クリーンアップの自動化

systemd-tmpfiles はすでに /tmp や一部のキャッシュを削除しています。apt キャッシュのクリーンアップを定期的に実行するには、cron エントリーを追加します:


# Clean the apt cache every Sunday at 03:00
0 3 * * 0 root /usr/bin/apt clean

これを /etc/cron.d/apt-clean として保存します。