apt-btrfs-snapshotによるディスク容量の消費

パソコンのディス容量がアップアップになっていたところを、今まで知らなかった方法で大きく改善した話。
一時的にディスフル(100%)になり、従来手法を使っても95%にしか減らず、それでは困るので別の手法を取り入れ、結果的に60%利用まで落ち着いた。

Ubuntuのリリースサイクルは半年毎であり、最新の版は先月でた19.10 eoanであるということは、先刻ご承知であろうかと思う。
そして、私のパソコン(のひとつ)では、約1年と少し前にSSDを交換した後も、何かとディスク容量の空きに余裕がなく、苦慮していた。

今回まずきっかけになったのは、VirtualBoxで動かしているWindows10のシステム更新をしたところ、問題発生、途中で停止したことによる。
ディスク容量が問題になっていることは、すぐに察した。今までに同様の件は経験済みである。

このパソコンで最もディスクを消費しているものは、そのWindows10のHDDイメージで、約51GiBであった。
これを、まだディスクには余裕がるもう一つのパソコンに移動した。
つまり今後はVirtualBoxはそちらのほうで使うことにした。

これでディスクには大きく余裕ができるハズだろうと思ったのに…。なんと100%→95%になっただけ。残り約10GiB。
これは何かがおかしいと思って、イロイロ調べることにした。

dfや「btrfs filesystem usage /」で見ると、ディスクの割当て済みがほぼ100%近く、空きは上記のように約10GiBと表示される。
いっぽう、duやbaobabで調べる、つまり個々のファイルの大きさを積算していく方式で調べると、それは約53GiBであると判った。
これは、驚きを持って受け止められれるべき事柄でありつつ、たしかに、冷静に考えると(ある点を除いて)妥当だと納得いく数字。

つまり、妥当であるのは、パソコンの利用状況などを考慮すれば、使用済みが53GiBであるという事実。200GiB超も使っているというほうが変だ。
そして納得できない、分からないのが、ディスク容量の使用済み(実数)と空きの合計が、ディスク(というよりパーティション)として確保している大きさに一致しないこと。
170GiB以上も、謎の差分があることになる。

これは、古き伝統的(そしてごく単純な)ファイルシステムを管理していた頃の知識からは、ありえない、異常事態としか言いようがない。
しかしここはもはや、Btrfsの世界なのである。
なので、何を調べるべきかは、だいたい想像できることではあるのだ。ただ、私の経験と知識では、まだ知らない何かがあるのだろう、ということ。

調べた。
その結果に辿り着いた答えが、aptのスナップショット機能によるものだったというわけ。
apt-btrfs-snapshotを使うと、それを確認でき、削除を含む管理ができる。
一番あたらしいものを一つだけ残して、あとは削除した。

Ubuntuをインストールしているシステムのファイルシステムとして、Btrfsを使っている場合、アップグレードのタイミング等で、自動的にaptがスナップショットを保存する。
そして冒頭のリリースサイクルの話に繋がるが、当パソコンでは、cosmic、disco、eoanという3回のアップグレードを経ており、この通り蓄積が大きくなっていたわけ。
これは全て自動的に行われており、今までまったく意識していなかった。
ファイルシステムのスナップショット機能があることは理解していたし、それを使えば相応にディスク容量が消費されるのはまったく道理なのだが、自分で能動的にスナップショット機能を利用したことはないため、当初は思いに至らなかった。
また同時に、スナップショットの保存によって消費された分が、システム的に、具体的にはdf等にどのように反映される(見える)のかは、知らないでいた。
まぁ、「見えない数字」になるということが、今回判った。

そして私は、この貴重な経験と共に、十分に余裕があるディスクスペースを確保することに成功した。
今後も、半年毎のリリースのたびに、このことを思い起こして不要なスナップショットを手動で削除する必要があるだろう…。