スナップショットは、領域管理にとって興味深い問題を抱えています。スナップショットは、ある特定の時点でシェアによって参照される物理ブロックのセットを表します。最初は、このスナップショットで追加の領域が消費されることはありません。しかし、新しいデータが新しいシェア内で上書きされると、アクティブなシェア内のブロックには新しいデータのみが含まれ、古いブロックは最新 (および場合によっては古い方) のスナップショットによって「保持」されます。アクティブなシェア内で内容が分岐するにつれて、スナップショットが徐々に追加の領域を消費するようになる可能性があります。所定のサイズのファイルシステムのスナップショットを取り、ファイルシステム内のデータを 100% 書き換える場合は、最初にファイルシステム内にあったデータの 2 倍のデータへの参照を維持する必要があります。
各スナップショットには、一意の領域と参照領域という 2 つの関連する領域統計があります。参照領域の量は、スナップショットが取られたときにファイルシステムによって消費された合計領域です。これは、スナップショットがすべてのデータブロックへの唯一の参照であり続けた場合に、そのスナップショットの理論上の最大サイズを表します。一意の領域は、現在のスナップショットによってのみ参照される物理領域の量を示します。スナップショットが破棄されると、一意の領域はプールの残りで使用できるようになります。
すべてのスナップショットで消費される領域の量は、すべてのスナップショットにまたがる一意の領域の合計と同じではありません。1 つのシェアと 1 つのスナップショットがある場合、すべてのブロックは、そのスナップショット、シェア、またはその両方によって参照される必要があります。しかし、複数のスナップショットがある場合は、特定のスナップショットではなく、スナップショットの一部のサブセットによってブロックを参照できます。たとえば、ファイルを作成し、2 つのスナップショット X と Y を取り、そのファイルを削除して、別のスナップショット Z を取った場合、ファイル内のブロックは X と Y によって保持され、Z では保持されません。この場合、Z を破棄しても領域は解放されませんが、X と Y の両方を破棄すると解放されます。このことから、スナップショットを破棄すると、隣接したスナップショットによって参照される一意の領域が影響を受ける可能性があります。ただし、スナップショットで消費される領域の合計量は常に減少します。
使用状況の内訳も利用できますが、プロジェクトまたはシェアの合計サイズは、常にすべてのスナップショットによって消費される領域から成ります。割り当て制限と予約をプロジェクトレベルで設定すると、この合計領域全体に物理的な制約を強制できます。また、割り当て制限と予約をファイルシステムレベルで設定して、これらの設定を参照データのみまたは合計データに適用できます。
割り当て制限と予約を参照データまたは合計物理データに適用するかどうかは、管理環境によって異なります。通常、ユーザーがスナップショットを管理していない (つまり、自動スナップショットスケジュールが設定されている) 場合には、割り当て制限の計算にスナップショットは含まれません。それ以外の場合、領域不足になっているのにファイルを削除できず、ユーザーが困惑する可能性があります。スナップショットの知識とそれらのスナップショットを管理する手段がなければ、管理者の介入なしにそのような状況を修復できなくなる可能性があります。このシナリオでは、スナップショットは、バックアップ機能を提供するためにシステムの動作に含まれるオーバーヘッドコストを表しています。一方、物理領域の要件に従ってユーザーが課金される環境もあります。その場合、スナップショットは、ユーザーがデータセットの解約率を考慮して要件を満たす、ある程度のバックアップを確保できる選択肢となります。このような環境では、スナップショットを含め、物理データの合計に基づいて割り当て制限を強制する方が理にかなっています。スナップショットのコストを理解すれば、ユーザーは (アプライアンスの専用のロールを使用して) スナップショットをアクティブに管理する手段を手に入れることができます。
関連トピック