共有のクォータのサイズを変更した後、なぜボリュームを「サイズ変更」する必要があるのでしょうか。
NetAppファイラーに1つのボリュームがあり、CIFSとして共有される複数のQtreeがあります。共有のサイズを変更するには、通常、次のようにします。
- 共有のクォータを変更する
- ボリュームで「サイズ変更」コマンドを使用します
何かが足りないかもしれませんが、なぜボリュームを「サイズ変更」する必要があるのでしょうか。クォータを変更しても、ボリュームのサイズは変更されません。おそらく、私が理解していない他の内部があります。
quota resize（またはGUIの1つでの同等のアクション）は、クォータサービスにボリュームをスキャンさせ、/ etc/quotasに加えられた変更を適用します。実際にボリュームのサイズを変更しているわけではありません。クォータのサイズ変更を実行する（またはクォータサービスを無効にしてから再度有効にする）まで、クォータ定義に加えられた変更は適用されません。また、注目すべきは、サイズ変更で開始したスキャンの実行にかかる時間中、クォータは適用されないことです。これは、qtreeの代わりにネットワーク共有に個別のボリュームを使用する良い理由です。
Qtreeの代わりにボリュームを使用するもう1つの理由は、このデータのバックアップ方法によっては、10個の1TBボリュームをバックアップするよりも10個の1TBqtreeを含む単一の10TBボリュームをバックアップするのにかなり長い時間がかかる可能性があることです。
皆さんのことはわかりませんが、ボリューム内でqtreeを使用した理由は、集計をオーバープロビジョニングすることなく、シェアをオーバープロビジョニングできるようにするためです。 CIFSボリュームに十分なスペースを維持できなくても、アグリゲートに十分なスペースを維持できなかった場合のように、他のボリュームが停止することはありません。
誰かをスリープ状態にする必要がある場合、またはクォータコマンドラインの適切なリファレンスが必要な場合は、 this outを確認してください。