どうもこんばんわ。システム運用担当のButameronです。
トラブル対応の備忘録として時々不定期にこんな記事も書いていこうと思います。


OPAP-JPでは、定期的な簡易バックアップにbtrfsのスナップショット機能を使っています。
（オンラインfsckすらない実験的なファイルシステムを実運用で使うというあたり、壊滅的にダメな人です。どうもこんばんわ。）

これの良いところは、Copy on Writeの仕組みでストレージを効率的に使えることです。
あるファイルを一切変更しなければ、いくらそのスナップショットを作ってもほぼそのファイルひとつ分だけの領域だけしか占拠しません。限られたストレージ容量を効率的に使いながらファイルの履歴を保存するという用途に重宝するというわけです。（上手く使えば、遠隔バックアップも効率的に行うことができます）

さて、ConoHa支援プログラム でVPSの無償提供を受け始めてから数ヶ月、上記のような感じでしばらく調子よく運用していたはずなのですが、最近、ストレージ容量がじわじわと圧迫されてきていることに気がつきました。ファイル容量は全体で30GB程度しかないはずなのに、気がつけばストレージの半分が消費されています。これは間違いなくスナップショットのしわざです。

クオータを有効にして、btrfsQuota.py で調べたところ、どうもそれぞれのスナップショットが排他的に2GBを消費しているという状況。

sudo btrfs quota enable /
sudo btrfs quota rescan /
sudo btrfsQuota.py /



ということは、どこかに定期的に書き換わる2GBぐらいのファイルがあるということです。
findコマンドで2GB以上のファイルを探すと、ありました。

「/var/lib/mlocate/mlocate.db」


これは、ファイルの一覧を保存しているデータベースのようですが、なぜか2GB以上にまで肥大化しています。尋常ではありません。

なぜこんなに肥大化したのか。
大量のスナップショットと、恐らく、その内部のシンボリックリンクの無限ループ。
スナップショットは/var/snapshots的な場所に作成していたため、mlocateの探索対象となっていたのです。それだけでも数十倍のファイル数になりますが、もしかすると、どこかにシンボリックリンクのループが形成されていて、無限にファイルが記録されていくという恐ろしいことが起きていたのかもしれません。

そして、mlocate.dbはcronか何かで定期的に書き換えられるため、ほぼ全てのスナップショットにそれぞれ中身が違う2GBのmlocate.dbが存在し、結果として「スナップショット数×2GB」の容量を消費していたのでした。


犯人が分かればあとは対策するだけです。

まず、/etc/updatedb.conf を編集し「PRUNEPATHS」に除外するディレクトリを追記します。

あとは、以下のコマンドを実行してmlocate.dbを再構築すれば完了です。
sudo rm /var/lib/mlocate/mlocate.db
sudo updatedb 


この結果、mlocate.dbは12MBにまで小さくなりました。
いやはやビックリです。