Data Domainの圧縮技術では、最先端の技術を使用して、お客様のデータに必要な物理スペースを削減します。そのため、圧縮レベルに関するテクノロジーと測定は複雑なトピックです。このドキュメントでは、Data Domainシステムで使用される圧縮タイプ、用語、および圧縮のその他の側面をより適切に説明するために、いくつかの用語、利点とそれに伴う欠点、測定について説明します。
適用対象:
すべてのData Domainモデル
最終更新日: 2024
年1月 圧縮は、より少ない物理スペースを使用してデータセットを保存することを目的としたデータ削減テクノロジーです。Data Domainシステム(DDOS)では、重複排除とローカル圧縮を実行してユーザー データを圧縮します。重複排除は、冗長データ セグメントを識別し、一意のデータ セグメントのみを格納するために使用されます。ローカル圧縮では、次のような特定の圧縮アルゴリズムを使用して一意のデータ セグメントがさらに圧縮されます。 lz, gzfast, gzといった具合です。DDOSでの全体的なユーザー データ圧縮は、重複排除とローカル圧縮を組み合わせた作業です。DDOSは、「圧縮比」を使用してデータ圧縮の有効性を測定します。一般的には、圧縮データの合計サイズまたは使用されている物理領域のサイズに対するユーザー データの合計サイズの比率です。
Data Domainファイル システムは、「ログ構造」の重複排除ファイル システムです。ログ構造ファイル システムは、データをシステムに追加するのみで、削除だけでは物理スペースを解放できません。このようなファイル システムは、不要になったスペースを再利用するためにガベージ コレクションに依存しています。ログ構造化ファイル システムの特性と重複排除テクノロジーを組み合わせることで、DDOSでの圧縮のすべての側面を明確に理解することは困難です。
圧縮については、測定できる側面が数多くあります。このドキュメントでは、DDOS圧縮を理解するために役立つ詳細について順を追って説明します。最初に、システム全体の圧縮効果について説明します。これは、Data Domainシステムで実現される現実的な圧縮、ユーザー データの量、消費される物理スペースの量、およびそれらの比率を示します。このドキュメントでは、この比率を「システムの実効圧縮比」と呼びます。DDOSは、インラインで重複排除を実行し、元のユーザー データ セグメント、重複排除後の一意のデータ セグメント、一意のデータ セグメントに対するローカル圧縮効果の統計を追跡します。これらのインライン圧縮統計情報は、インライン圧縮効果を測定するために使用されます。インライン圧縮統計は、書き込みごとに測定できます。また、DDOSはさまざまなレベルで統計を追跡します。ファイル、MTree、システム全体です。
このドキュメントの内容は、このドキュメントが公開されるまでのすべてのDDOSリリース(DDOS 7.13まで)に適用できます。今後のリリースでは、すべてのコンテンツが正確であるという保証はありません。5.0より前のリリースでは、システム全体にmtreeが1つしかなく、mtreeという用語は明示的に呼び出されません。
システム全体の圧縮効果は、システムの実効圧縮比によって測定されます。実効圧縮比は、ユーザー データ サイズと使用済み物理領域のサイズの比率です。これは、「filesys show compression (FSC)」CLIコマンドによって報告されます(対応する情報はUIでも確認できます)。 FSCの出力例を以下に示します。
# filesys show compression
From: 2023-12-31 03:00 To: 2024-01-07 03:00
Active Tier:
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
---------------- -------- --------- ----------- ---------- -------------
Currently Used:* 6439.6 113.4 - - 56.8x (98.2)
Written:
Last 7 days 135421.3 1782.0 35.1x 2.2x 76.0x (98.7)
Last 24 hrs 532.5 1.5 334.3x 1.1x 356.5x (99.7)
---------------- -------- --------- ----------- ---------- -------------
* Does not include the effects of pre-comp file deletes/truncates
since the last cleaning on 2024/01/05 11:34:13.
システムの実効圧縮比は、CLI出力の結果セクションの行1で報告されます。上の行はハイライト表示されています。ユーザー データの合計サイズは「Pre-Comp」とラベル付けされます。消費された物理スペースの合計(データとメタデータの両方)は、「Post-Comp」とラベル付けされます。
「Pre-Comp」番号と「Post-Comp」番号はどちらも実行時に読み取られます。FSCはシステム全体を暗黙的に同期し、その2つの数値をクエリーします。これら 2 つの数値は、「filesys show space」コマンドと同じ方法で測定されます。
システム実効圧縮比 = Pre-Comp/Post-Comp
FSC出力の残りの部分では、インライン圧縮の統計情報が説明されています。これについては後で説明します。
システムの実効圧縮比に影響を与える可能性のある操作がいくつかあります。
ファストコピー
アクティブなネームスペース内のファイル(スナップショットではない)からfastcopyを実行すると、ターゲット ファイルに追加の物理領域が必要ないため、完全な重複排除となります。fastcopyの効果は、追加の物理スペースを消費することなく、ユーザー データ サイズを増やせることです。これにより、システムの実効圧縮比が向上します。多数のfastcopyが実行されると、システムの実効圧縮比が不自然に高くなる可能性があります。
仮想合成
仮想合成バックアップでは、システムの実効圧縮比が高くなる傾向があります。これは、仮想合成が論理フル バックアップを作成しますが、変更されたデータまたは新しいデータのみをData Domainシステムに転送するためです。仮想合成がシステムの実効圧縮比に与える影響は、fastcopyの効果と多少似ています。
上書き
上書きはより多くの物理領域を消費しますが、データセットの論理サイズは増加しないため、上書きはシステムの実効圧縮比を低下させます。
スパース ファイルの保存
スパース ファイルには、論理サイズにカウントされる大きな「穴」が含まれますが、圧縮により物理スペースを消費しません。その結果、システムの実効圧縮比が高く見えることがあります。
小容量ファイルの保存
DDOSは、特定の内部メタデータについて、各ファイルに約1 KBのオーバーヘッドを追加します。システムに大量の小容量ファイル(サイズが1 KB未満または1桁のキロバイト)が格納されている場合、メタデータのオーバーヘッドによって実効圧縮比が低下します。
事前に圧縮または暗号化されたファイルの保存
圧縮と暗号化により、データ変更のレベルが増大し、重複排除の可能性が低下する可能性があります。このようなファイルは通常、重複排除がうまくできず、システムの実効圧縮比が低くなります。
削除
削除により、システムの論理サイズは減少しますが、ガベージ コレクションが実行されるまで、システムは対応する未使用スペースを取得しません。多くの削除されたファイルでは、ガベージ コレクション(GC)が実行されるまで圧縮比が低くなります。
ガベージ コレクション(GC)またはクリーニング
GCは、どのファイルにも表示されなくなったデータ セグメントによって消費された領域を再利用します。最近多くのファイルが削除された場合、GCは物理スペースの消費フットプリントを減らすことで、システム圧縮比を高めることがあります。
積極的にスナップショットを作成する
Mtreeのスナップショットを作成する場合、データセットの論理サイズは変更しません。ただし、スナップショットによってキャプチャされたすべてのファイルがスナップショットの作成後に削除された場合でも、スナップショットによって参照されるすべてのデータ セグメントをロックダウンする必要があります。GCは、スナップショットがまだ必要としているスペースを再利用できません。したがって、スナップショットが多数あると、システムの実効圧縮比が低く見える場合があります。ただし、スナップショットは便利なクラッシュ リカバリー機能です。躊躇せずに、必要に応じてスナップショットを作成したり、適切なスナップショット スケジュールを設定したりしてください。
DDOSは、データがシステムに書き込まれると、インラインで重複排除を実行します。書き込みごとにインライン重複排除とローカル圧縮の効果を追跡し、ファイル レベルで統計情報を蓄積します。ファイル単位のインライン圧縮統計情報は、mtreeレベルとシステム レベルでさらに集計されます。圧縮は、インライン統計の次の3つの数値に基づいて測定されます。
上記の3つの数値に基づいて、DDOSはさらに2つの細かい粒度の圧縮比を定義します。
累積インライン圧縮統計は、DDOSのファイル メタデータの一部であり、ファイルのinodeに格納されます。DDOSには、3つのレベルすべてでインライン圧縮をチェックするためのツールが用意されています。ファイル、MTree、システム全体。次のセクションで詳しく説明します。
3.1 ファイル圧縮
ファイルの圧縮は、ファイルのinodeに格納されている累積圧縮統計情報をレポートする「filesys show compression <path>」CLIコマンドで確認できます。ディレクトリーを指定すると、そのディレクトリーの下にあるすべてのファイルのインライン圧縮統計が合計され、レポートされます。CLI出力では、raw_bytesは「Original Bytes」とラベル付けされます。pre_lc_sizeは「Globally Compressed」とラベル付けされます。post_lc_bytesは「ローカル圧縮」としてマークされます。その他のオーバーヘッドは「メタデータ」として報告されます。2つの例は、実際のDDからキャプチャされています。例
1: ファイルのインライン圧縮統計
# filesys show compression /data/col1/main/dir1/file_1
Total files: 1; bytes/storage_used: 7.1
Logical Bytes: 53,687,091,200
Original Bytes: 11,463,643,380
Globally Compressed: 4,373,117,751
Locally Compressed: 1,604,726,416
Meta-data: 18,118,232
例 2：ディレクトリーの下のすべてのファイル(すべてのサブディレクトリーを含む)のインライン圧縮統計
# filesys show compression /data/col1/main/dir1
Total files: 13; bytes/storage_used: 7.1
Logical Bytes: 53,693,219,809
Original Bytes: 11,501,978,884
Globally Compressed: 4,387,212,404
Locally Compressed: 1,608,444,046
Meta-data: 18,241,880
システムは、上記のCLI出力で全体的なインライン圧縮比を「bytes/storage_used」として報告します。 ただし、さまざまな理由で誤解を招く可能性があるため、上記の情報の解釈には注意が必要です。その理由の1つは、データ操作の処理時にpre_lc_sizeとpost_lc_sizeが記録されるためです。これらのセグメントを最初に追加したファイルが削除されると、残りのファイル内の一意のデータ セグメントの数を増やす必要があります。
たとえば、sample.fileファイルがData Domainにバックアップされ、最初のバックアップでファイルの圧縮情報がpre_lc_size=10GiB、post_lc_size=5GiBであるとします。
次に、このファイルのデータが一意であり、他のファイルとデータを共有していないと仮定します。ファイルの2回目のバックアップでは、さらに、ファイルのすべてのセグメントがすでにシステムに存在しているため、pre_lc_sizeとpost_lc_sizeの両方がゼロになるなど、ファイルが理想的な重複排除を取得すると仮定します。最初のバックアップが削除されると、ファイルの2番目のバックアップが、5 GiBのデータ セグメントを参照する唯一のファイルになります。この場合、理想的には、2番目のバックアップ内のファイルのpre_lc_sizeとpost_lc_sizeを両方ともゼロから、それぞれ10 GiBと5 GiBに更新する必要があります。ただし、どのファイルに対して実行する必要があるかを検出する方法がないため、既存のファイルのインライン圧縮統計は変更されません。
上記の数値に影響を与える別の要因は、累積統計です。ファイルが大量の上書きを受けると、ライブ データを導入した書き込みが累積統計にどの程度反映されているかを追跡することは不可能です。したがって、長期間にわたってインライン圧縮統計は、特定のファイルの圧縮を大まかに推定するためのヒューリスティックとしてのみ扱うことができます。
もう1つ注目すべき事実は、ファイルのインライン圧縮は任意の時間間隔で測定できないことです。ファイルのインライン圧縮統計は累積された結果であり、ファイルがこれまでに受信したすべての書き込みを対象とします。ファイルが大量の上書きを受け取ると、raw_bytesはファイルの論理サイズよりもはるかに大きくなる可能性があります。スパース ファイルの場合、ファイル サイズは「Original Bytes」よりも大きくなる可能性があります。
3.2 MTree圧縮
特定のMTreeの圧縮は、 "mtree show compression" (MSC)CLIコマンドを使用します。インライン圧縮統計の絶対値は、MTreeの有効期間にわたって累積されます。MTreeの有効期間が何年も長くなることを考えると、これらの値は時間の経過とともに情報量が少なくなります。この問題に対処するために、インライン圧縮統計の変化量(デルタ)を使用し、特定の時間間隔の圧縮をレポートします。基本的なアプローチは、MTreeインライン圧縮統計を定期的にログにダンプすることです。クライアントがMSCコマンドを使用してMTree圧縮をクエリーすると、ログを使用して数値のデルタを計算し、圧縮レポートを作成します。デフォルトでは、MSCは過去7日間と過去24時間の圧縮をレポートしますが、対象となる任意の期間を指定できます。
例として、MTree Aの次のログを想定します。
3:00AM, raw_bytes=11000GB, pre_lc_size=100GB, post_lc_size=50GB 4:00AM, raw_bytes=12000GB, pre_lc_size=200GB, post_lc_size=100GB
この時間のMTree Aの圧縮率は次のようになります。
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
上記の圧縮比の計算では、データセットのサイズには何も影響しません。たとえば、上記のMTreeには500 GBの論理データしか含まれていない場合があります。
MSCは、「filesys show compression」コマンドと同様に、「daily」および「daily-detailed」オプションをサポートしています。「daily」を指定すると、コマンドはカレンダー方式で毎日の圧縮を報告します。また、raw_bytesとpost_lc_sizeの日次デルタを使用して、毎日の圧縮比を計算します。「daily-detailed」を指定すると、コマンドは各日の3つのデルタ(それぞれraw_bytes、pre_lc_size、post_lc_size)をすべて表示します。また、合計圧縮率とともにg_compとl_compも計算します。
これらのシステムからの出力例は 、付録にあります。
3.3 システム圧縮
MTreeで圧縮がどのように報告されるかを理解すれば、その概念をシステム全体に拡張するのは簡単です。システム全体のインライン圧縮統計の収集とレポート作成は、MTreeの場合とまったく同じです。唯一の違いはスコープです。1つは特定のMTreeに含まれるのに対し、もう1つはシステム全体に及ぶためです。結果は、「filesys show compression」コマンドを使用して確認できます。この例は、セクション2にあります。「過去7日間」と「過去24時間」のシステム圧縮が、FSC出力の結果セクションの最後の2行で報告されています。
クラウド階層が実装されたDDでは、ストレージは、2つの独立した重複排除ドメインであるアクティブ階層とクラウド階層に分離されます。ユーザーは、アクティブ階層にのみデータを挿入できます。その後、DDOSのデータ移動機能を使用して、アクティブ階層からクラウド階層にデータを移行できます。したがって、スペースと圧縮の測定とレポート作成は、各階層で個別に処理されます。ただし、ファイル レベルでは、階層による差別化は行わず、インライン圧縮統計をレポートします。これらは、セクション3.1で説明したものとまったく同じです。
最後に取り上げるのは、重複排除の特性です。これは、多くのData Domainドキュメントで「グローバル圧縮」と呼ばれています。「圧縮」という言葉が含まれていますが、DDOSが「ローカル圧縮」という名前で提供している従来の圧縮の概念とはまったく異なります。
ローカル圧縮は、特定のアルゴリズムを使用してデータのサイズを縮小します(一部の種類のデータは圧縮可能ではなく、圧縮アルゴリズムを適用するとデータ サイズがわずかに大きくなる場合があります)。通常、アルゴリズムが決定されると、データ自体が圧縮率の唯一の要因になります。
ただし、重複排除はローカルの概念ではなく、「グローバル」です。受信データ セグメントは、重複排除されたドメイン内のすべての既存のデータ セグメントに対して重複排除されます。これには、クラウド以外のData Domainシステム上のすべてのデータが含まれます。重複排除手順では、データ セグメント自体は重要ではありません。
実際には、データセットの初期バックアップで重複排除率が高くなることはめったにありません。初期バックアップでは、多くの場合、主なデータ削減はローカル圧縮によって行われます。後続のバックアップがData Domainに配置されると、重複排除がその強みを発揮し、圧縮の主要な要因になります。重複排除の有効性は、バックアップ間のデータセットの変更率が低いという事実に依存します。このため、変更率の高いデータセットは適切に重複排除できません。バックアップ アプリケーションが独自のメタデータ チャンク(Data Domainではマーカーと呼ばれる)を高頻度でバックアップ イメージに挿入する場合も、重複排除率が高くならない可能性があります。私たちのマーカー処理技術は、常に役立つわけではありませんが、役立つ場合があります。
これらの観察結果を踏まえて、私たちは何を期待できるでしょうか?
重複排除されたファイル システムでの圧縮の測定は困難ですが、ログ構造の重複排除されたファイル システムではさらに困難です。重複排除の仕組みと圧縮統計の追跡方法を理解する必要があります。圧縮比は、特定のシステムの動作を理解するのに役立つ情報です。システムの実効圧縮比は、最も重要で信頼性が高く、有益な尺度です。インライン圧縮の統計も役に立ちますが、状況によってはヒューリスティックに過ぎない場合があります。
付録: サンプル出力: "mtree show compression" コマンド
254792.4 GiBのデータを保持しているMTreeがあるとします。過去7日間で4379.3 GiB、過去24時間で78.4 GiBの新しいデータを受信しました(他の時間間隔を指定できます)。「daily」オプションは、過去33日間のインライン圧縮統計をレポートします。「daily-detailed」オプションを指定すると、グローバル圧縮比とローカル圧縮比に分けられ、合計圧縮比がさらに詳細になります。
Mtreeリストの出力:
# mtree list /data/col1/main Name Pre-Comp (GiB) Status --------------- -------------- ------ /data/col1/main 254792.4 RW --------------- -------------- ------ D : Deleted Q : Quota Defined RO : Read Only RW : Read Write RD : Replication Destination IRH : Retention-Lock Indefinite Retention Hold Enabled ARL : Automatic-Retention-Lock Enabled RLGE : Retention-Lock Governance Enabled RLGD : Retention-Lock Governance Disabled RLCE : Retention-Lock Compliance Enabled M : Mobile m : Migratable
# mtree show compression /data/col1/main
From: 2023-09-07 12:00 To: 2023-09-14 12:00
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
------------- -------- --------- ----------- ---------- -------------
Written:
Last 7 days 4379.3 883.2 3.4x 1.5x 5.0x (79.8)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
------------- -------- --------- ----------- ---------- -------------
「毎日」オプションの場合:
# mtree show compression /data/col1/main daily
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100
「毎日の詳細」オプションの場合:
# mtree show compression /data/col1/main daily-detailed
From: 2023-08-12 12:00 To: 2023-09-14 12:00
Sun Mon Tue Wed Thu Fri Sat Weekly
----- ----- ----- ----- ----- ----- ----- ------ -----------------
-13- -14- -15- -16- -17- -18- -19- Date
432.0 405.9 284.1 438.8 347.0 272.7 331.4 2511.8 Pre-Comp
85.5 66.2 45.3 81.9 61.4 57.4 66.3 464.1 Post-Comp
3.5x 4.1x 4.3x 3.6x 3.8x 3.3x 3.4x 3.7x Global-Comp Factor
1.4x 1.5x 1.5x 1.5x 1.5x 1.4x 1.5x 1.5x Local-Comp Factor
5.0x 6.1x 6.3x 5.4x 5.7x 4.7x 5.0x 5.4x Total-Comp Factor
80.2 83.7 84.1 81.3 82.3 78.9 80.0 81.5 Reduction %
-20- -21- -22- -23- -24- -25- -26-
478.0 387.8 450.2 533.1 386.0 258.4 393.6 2887.1
100.6 81.5 100.8 119.0 84.0 40.6 75.3 601.8
3.3x 3.3x 3.0x 3.0x 3.3x 4.1x 3.6x 3.3x
1.4x 1.5x 1.5x 1.5x 1.4x 1.5x 1.4x 1.5x
4.8x 4.8x 4.5x 4.5x 4.6x 6.4x 5.2x 4.8x
79.0 79.0 77.6 77.7 78.2 84.3 80.9 79.2
-27- -28- -29- -30- -31- -1- -2-
27.6 1.0 0.4 470.7 467.3 517.7 641.9 2126.7
4.9 0.2 0.1 83.9 92.3 89.8 140.1 411.2
4.4x 3.7x 2.6x 3.8x 3.5x 3.9x 3.2x 3.5x
1.3x 1.5x 1.6x 1.5x 1.4x 1.5x 1.5x 1.5x
5.6x 5.6x 4.3x 5.6x 5.1x 5.8x 4.6x 5.2x
82.1 82.2 76.8 82.2 80.3 82.7 78.2 80.7
-3- -4- -5- -6- -7- -8- -9-
539.6 495.0 652.8 658.7 537.1 398.7 305.5 3587.3
110.8 108.0 139.4 137.0 111.5 78.3 48.3 733.3
3.4x 3.1x 3.2x 3.4x 3.3x 3.4x 4.1x 3.3x
1.4x 1.5x 1.5x 1.4x 1.4x 1.5x 1.6x 1.5x
4.9x 4.6x 4.7x 4.8x 4.8x 5.1x 6.3x 4.9x
79.5 78.2 78.6 79.2 79.2 80.4 84.2 79.6
-10- -11- -12- -13- -14-
660.2 738.3 787.2 672.9 796.9 3655.5
143.9 152.5 167.6 126.9 163.3 754.2
3.1x 3.4x 3.2x 3.7x 3.4x .3x
1.5x 1.4x 1.5x 1.4x 1.5x 1.5x
4.6x 4.8x 4.7x 5.3x 4.9x 4.8x
78.2 79.3 78.7 81.1 79.5 79.4
----- ----- ----- ----- ----- ----- ----- ------ -----------------
Pre-Comp Post-Comp Global-Comp Local-Comp Total-Comp
(GiB) (GiB) Factor Factor Factor
(Reduction %)
-------------- -------- --------- ----------- ---------- -------------
Written:
Last 33 days 14768.3 2964.5 3.4x 1.5x 5.0x (79.9)
Last 24 hrs 784.6 162.1 3.3x 1.4x 4.8x (79.3)
-------------- -------- --------- ----------- ---------- -------------
Key:
Pre-Comp = Data written before compression
Post-Comp = Storage used after compression
Global-Comp Factor = Pre-Comp / (Size after de-dupe)
Local-Comp Factor = (Size after de-dupe) / Post-Comp
Total-Comp Factor = Pre-Comp / Post-Comp
Reduction % = ((Pre-Comp - Post-Comp) / Pre-Comp) * 100