私は、Btrfs をバッキング ストアとして使用して LXC を試しています。Btrfs を使用すると、スナップショット/重複排除が簡単に実行でき、複数の「疑似 VM」を起動するのに最適です。
私が抱えている問題は、テストしているアプリの一部が大量のデータをディスクにダンプしてしまうことです。Btrfs ボリュームの使用を制限しようとしているので、特定のコンテナ用に LXC によって作成されたサブボリュームにクォータを割り当てました。
アプリにはフェイルセーフ テストがあり、書き込み先のファイル システムの空きディスク領域が一定量 (例: 512 MB) 未満になると、古いログを消去して新しいログ用のスペースを確保します。
問題は、クォータが適用されていても、LXC ルート ファイルシステムがホスト Btrfs ファイルシステムのフル サイズを報告することです。
-B btrfs
例: Btrfs ファイルシステムが 250GB で、およびオプションを使用して LXC コンテナを作成すると-s
、Btrfs ファイルシステムにこの新しいコンテナのルートを表すサブボリュームが作成されます。次に、コンテナが使用するスペースを制限したいので、コンテナに 32GB の qgroup 制限を適用します。ただし、df
LXC コンテナでコマンドを実行すると、依然として合計ファイルシステム サイズが 250GB で、空き領域はホスト ファイルシステムの実際の空き領域にほぼ基づいて表示されます。つまり、クォータ制限は に表示されませんdf
。
つまり、ログ アプリはクォータ全体を使い切っても、書き込み可能な領域が 200 GB 以上あると認識し、古いデータを再利用しません。最終的にはクォータを超え、COW ファイルシステムの制限により、クォータを無効にして古いログを手動で削除する必要があります。クォータが同じサイズで引き続き適用される場合、削除操作のための余分な領域がないため、データを削除することはできません。
私は Btrfs について十分に読んで理解しているので、「空き領域」という概念は Btrfs ではわかりにくく、理解するのが難しい場合があることは理解していますが、LXC 内からクォータ領域の残り容量の「大まかな」数値を取得する方法はありますか? できれば、これはディスクの空き領域を取得するための標準 API (df
使用するもの) によって実行されるべきです。そうすれば、ファイルシステムにアクセスして、おおよその空き領域を知る必要がある他のアプリにも適用されるからです。
たとえば、実際の空き領域(クォータによって提供される)から 1 GB 程度以内に収めることができれば、ファイルシステムがクォータを超えないようにログ有効期限パラメータを調整するのに十分です。
答え1
以下は、btrfs サブボリュームのスペース割り当てを処理するために私が見つけた最適なツールです。 BTRFS スナップショットのサイズを取得する | PoisonPacket ブログ
すべてのクレジットは Kyle Agronick (このスクリプトの著者) に帰属します。