web-dev-qa-db-ja.com

ZFSでのシステム全体のクォータの設定

断片化を防ぐために、ZFSボリュームを70〜80％を超えていっぱいにしないことをお勧めします。しかし、私は過去にそれを超えていることに気づきました（「もう少し必要です。後でクリアします」-症候群）。すぐに一部のボリュームを新しいボリュームに移行して、それらが再び「クリーン」になるようにし、そのボリュームに制限を適用したいと思います。基本的に、私がその障壁を越えるのを防ぐためのすべてのユーザーの割り当て。

それで、それは単に以下を設定するのと同じくらい簡単ですか（この場合は3TBのディスクを想定しています）？

zfs set quota=2000G storage/data

もしそうなら、代わりにここでパーセンテージを使用することは可能ですか？

最後に、ボリュームが大きい場合でも、推奨値は70〜80％です。または、保存/コピーする可能性のある最大のファイルにxの量を掛けて、より妥当な量を計算する必要があります（監視をスローするように設定しない場合と同様）。 10EBボリュームの90％で重大なアラートが発生しますが、平均データ増加を計算し、代わりにもっと現実的なものを設定しますか？

グーグルで最初の質問を見つけることができると思いますが、最後の質問は専門家を対象としています。

filesystemszfsdefragment
2
Mark

理由はわかりませんが、私の最初の本能は、割り当てではなく予約を使用することでした。私は（誤って）スーパーユーザーがクォータを回避できるかもしれないと思いましたが、簡単なテストで私の勘が間違っていたことがわかりました。

ただし、啓蒙のために、クォータの代わりに予約を使用することを検討してください。

zfs create \
    -o reservation=500G \
    -o canmount=off \
    -o mountpoint=none storage/unusable

クォータと予約は補完的な番号を使用することに注意してください。あなたの例では、2000GBのサイズの数字はあなたが欲しい使用可能スペースの量です。上記の予約例では、500GBは、プールの合計スペースから差し引かれる使用不可スペースの量です。好みに合わせて調整します。

違いは小さいので、これを「より良い方法」としてではなく、単なる代替ソリューションとして提案します。ただし、わずかな利点が1つあり、それは将来のある日まで報われない可能性があります。

クォータを使用すると、スーパーユーザーとしても、その予約済みスペースを使用できなくなります。ただし、予約すると、スーパーユーザーはそのスペースにアクセスできる可能性があります。

zfs set canmount=noauto,mountpoint=/root/temporary storage/unusable
zfs mount /root/temporary

プールの使用できない部分に緊急アクセスできます。クォータがあるので、スーパーユーザーでさえストレージ制限を上書きする方法を私は知りません。

編集：

予約がプールに対して行うことを説明するために、1G予約の小さな4G仮想ディスクプールを次に示します。

# zfs list -o name,used,avail,reservation,refer,mountpoint -r mypool
NAME              USED  AVAIL  RESERV  REFER  MOUNTPOINT
mypool           1.00G  2.62G    none    88K  /mypool
mypool/unusable    88K  3.62G      1G    88K  none
mypool/usable      88K  2.62G    none    88K  /mypool/usable

# zpool list mypool
NAME     SIZE  ALLOC   FREE  CKPOINT  EXPANDSZ   FRAG    CAP  DEDUP  HEALTH  ALTROOT
mypool  3.75G   744K  3.75G        -         -     0%     0%  1.00x  ONLINE  -
2
Jim L.