現在btrfsサブボリュームに設定されている割り当て制限を取得する方法を判断できません。 クォータのbtrfs wiki はこれを示していないようです。
これは私が知っていると私が思うことです:
btrfs qgroup limit 21G /path
btrfs qgroup show /path
しかし、すでに設定されている制限を確認するにはどうすればよいですか?
オプションを使用-r
および-e
:
btrfs qgroup show -pcre /path
指定したパスの各サブボリュームの割り当て制限と使用済みスペースも表示する簡単なスクリプトを作成しました。構文は非常に簡単です:
./quota.sh path
すべてのサブボリュームの使用済みスペースを出力するには、-aフラグを使用します。
./quota.sh path -a
スクリプトに実行権限を追加することを忘れないでください。
#! /bin/sh
volumes=$(btrfs subvolume list $1 | cut -d " " -f 9 )
snapshots=$(btrfs subvolume list -s $1 | cut -d " " -f 14 )
regsnap=$(echo $snapshots | sed 's/ /,/g')
normalv=$(echo $volumes | sed "s/\($regsnap\)//g" )
if [ ! -z "$snapshots" ] ; then
echo SNAPSHOTS
for p in $snapshots; do
quot=$(btrfs qgroup show -rF $1/$p | tail -1)
if [ -z $2 ]; then
(echo $quot | grep -q none) || echo $p $quot
else
[ "$2" == "-a" ] && echo $p $quot
fi
done
fi
if [ ! -z "$normalv" ] ; then
echo SUBVOLUMES
for p in $normalv; do
quot=$(btrfs qgroup show -rF $1/$p | tail -1)
if [ -z $2 ]; then
(echo $quot | grep -q none) || echo $p $quot
else
[ "$2" == "-a" ] && echo $p $quot
fi
done
fi
最初に従来のサブボリュームを印刷し、スナップショットボリュームの下に印刷します。出力例:
SNAPSHOTS
Apple 0/258 1.32MiB 16.00KiB 20.00MiB
SUBVOLUMES
citrus/orange 0/256 1.32MiB 16.00KiB 20.00MiB
私たちが話すように、btrfsはこの点で設計上壊れています。
現在、btrfs-progsには、どのサブボリュームにどの割り当てが割り当てられているかを表示する機能はありません。抽象割り当てを解析するために、スクリプト(およびbtrfsに失敗した人)を記述する必要があります。出力するグループ番号、およびそれらの下にあるクォータグループ内のサブボリュームを一覧表示します。追加することもできますが、btrfs開発者はこれを行うことを熱心に拒否します。
さらに悪いことに、だけではありません現在、サブボリュームが使用している割り当て量を表示する方法はありません。これが、df
のみが表示される理由です総空き容量。 btrfsがコアで設計されているため、これを行うことはできません。これサブボリュームはスナップショットのように機能するためです。つまり、サブボリューム内のデータ量を調べるには、ファイルシステム全体をスキャンし、そのサブボリューム/スナップショットにリンクされているすべてのファイルを見つけて追加する必要があります。 du
コマンドと同じです。これには時間がかかります。 btrfsが割り当てがいっぱいであることをどのようにして知っているのか、私にはわかりません…IRCチャネルは、それに対する答えを提供できませんでした。 (彼らは壊れやすい過膨張した自我を守るために忙しくしていました。)賢明なことは、データが追加または削除されるたびにサブボリュームカウンターを変更することです。 btrfsがそれがいっぱいであることをどのように認識しているのでしょうか。少なくとも他の方法は知りません。しかし、なぜ彼らがこの入手可能な情報を基本的に軍事的に守られた国家機密を保持することを選択したのか、私にはわかりません…
Zfsにこのような異常なRAM要件がない場合(TBごとに1GB…例:シングルボードARMコンピュータのオプションではない)およびデータのリスク早期にデータを書き込まないため、クラッシュ保護を備えたサーバー用に設計されているため、損失 btrfs をダンプすることをお勧めします。