Методы сжатия, используемые в Data Domain, используют самые современные методы для сокращения физического пространства, необходимого для данных заказчика. Таким образом, технологии и измерения уровней сжатия — это непростые темы. В этом документе обсуждаются некоторые терминологии, компромиссы и меры, чтобы лучше объяснить используемые типы сжатия, терминологию и другие аспекты сжатия в системе Data Domain.
ОБЛАСТЬ ПРИМЕНЕНИЯ:
Все модели Data Domain
Последнее обновление: Январь 2024
г. Сжатие — это технология сокращения объема данных, которая предназначена для хранения набора данных, использующей меньше физического пространства. В системах Data Domain (DDOS) мы выполняем дедупликацию и локальное сжатие для сжатия пользовательских данных. Дедупликация используется для идентификации избыточных сегментов данных и сохранения только уникальных сегментов данных. Локальное сжатие дополнительно сжимает уникальные сегменты данных с помощью определенных алгоритмов сжатия, таких как: lz, gzfast, gzи так далее. Общее сжатие пользовательских данных в DDOS — это совместная работа дедупликации и локального сжатия. DDOS использует «коэффициент сжатия» для измерения эффективности сжатия данных. Как правило, это отношение общего размера пользовательских данных к общему объему сжатых данных или объему используемого физического пространства.
Файловая система Data Domain представляет собой файловую систему дедупликации со структурой журналов. Файловая система, структурированная по журналу, только добавляет данные в систему, и просто удаление не может освободить физическое пространство. Такие файловые системы полагаются на чистку памяти для высвобождения неиспользуемого пространства. Характеристики файловой системы со структурированным журналом и технология дедупликации, объединенные вместе, затрудняют четкое понимание всех аспектов сжатия в DDOS.
Для сжатия есть много аспектов, которые мы можем измерить. В этом документе мы обсудим подробности шаг за шагом, чтобы помочь понять сжатие DDOS. Сначала мы объясним общий эффект сжатия системы, который говорит нам о реалистичном сжатии, достигаемом в системе Data Domain, объеме пользовательских данных, объеме потребляемого физического пространства и их соотношении. В данном документе этот коэффициент называется «эффективным коэффициентом сжатия системы». DDOS выполняет дедупликацию на лету и отслеживает статистику исходных сегментов пользовательских данных, уникальных сегментов данных после дедупликации и влияние локального сжатия на уникальные сегменты данных. Эти статистические данные о сжатии на лету используются для измерения эффекта сжатия на лету. Для каждой записи можно измерять статистику сжатия на лету. Также DDOS отслеживает статистику на разных уровнях; файлов, MTree и всей системы.
Содержимое этого документа может применяться ко всем выпускам DDOS до публикации этого документа, вплоть до DDOS 7.13. Мы не гарантируем, что все содержимое будет точным для будущих выпусков. В выпусках до 5.0 вся система имеет только одно mtree, и термин mtree не вызывается явным образом.
Общий эффект сжатия в масштабе системы измеряется коэффициентом эффективного сжатия системы, который представляет собой отношение объема пользовательских данных к размеру используемого физического пространства. Об этом сообщает CLI-команда filesys show compression (FSC) (соответствующая информация также доступна в пользовательском интерфейсе). Пример выходных данных 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.
Эффективный коэффициент сжатия системы указывается в строке 1 раздела результатов выходных данных интерфейса командной строки. Строка выделена выше. Общий размер пользовательских данных помечен как «Pre-Comp». Общее потребленное физическое пространство (как по данным, так и по метаданным) помечается как Post-Comp.
Номер «Pre-Comp» и номер «Post-Comp» считываются во время выполнения. FSC неявно синхронизирует всю систему, затем запрашивает два числа. Эти два числа измеряются так же, как и команда «filesys show space».
Эффективный коэффициент сжатия системы = до начала работы/после
сжатия Остальные выходные данные FSC описывают встроенную статистику сжатия, о которой мы поговорим позже.
Существует ряд операций, которые могут повлиять на эффективный коэффициент сжатия системы:
Быстрая копия
Быстрая копия выполняется из файла в активном пространстве имен (не из моментального снимка), что является идеальной дедупликацией, так как для целевого файла не требуется дополнительное физическое пространство. Результатом применения быстрого копирования является то, что мы увеличиваем размер пользовательских данных без использования дополнительного физического пространства. Это увеличивает эффективную степень сжатия системы. Когда выполняется большое количество быстрых копий, эффективный коэффициент сжатия системы может стать искусственно завышенным.
Виртуальная синтетика
Виртуальные синтетические резервные копии, как правило, показывают высокий эффективный коэффициент сжатия системы. Это связано с тем, что виртуальные синтетические устройства создают логические полные резервные копии, но передают в системы Data Domain только измененные или новые данные. Влияние виртуальных синтетических материалов на эффективную степень сжатия в системе чем-то похоже на эффект быстрого копирования.
Перезаписывает
Перезаписи занимают больше физического пространства, но не увеличивают логический размер набора данных, поэтому перезаписи снижают эффективный коэффициент сжатия системы.
Хранение разреженных файлов
Разреженные файлы содержат большие «пробелы», которые учитываются в логическом размере, но не занимают физическое пространство из-за сжатия. В результате эффективное сжатие системы может казаться более высоким.
Хранение небольших файлов
DDOS добавляет дополнительные затраты около 1 Кбайт на каждый файл для определенных внутренних метаданных. Если в системе хранится значительное количество небольших файлов (размером менее 1 Кбайт или однозначными килобайтами), издержки метаданных снижают эффективный коэффициент сжатия.
Хранение предварительно сжатых или зашифрованных файлов
Сжатие и шифрование могут повысить вероятность изменения данных и уменьшить вероятность дедупликации. Такие файлы, как правило, плохо дедуплицируются и снижают эффективный коэффициент сжатия системы.
Удаляет
Удаления уменьшают логический размер системы, но система не получает соответствующее неиспользуемое пространство до запуска чистки памяти. При удалении многих файлов коэффициент сжатия снижается до тех пор, пока не будет запущена чистка мусора (GC).
Сборка мусора (GC) или очистка
GC освобождает пространство, занимаемое сегментами данных, которые больше не видны ни одному файлу. Если большое количество файлов было удалено недавно, GC может увеличить коэффициент сжатия системы за счет сокращения занимаемого пространства.
Активное создание моментальных снимков
При создании моментального снимка MTree логический размер набора данных не изменяется. Однако все сегменты данных, на которые ссылается моментальный снимок, должны быть заблокированы, даже если все файлы, захваченные моментальным снимком, удаляются после создания моментального снимка. GC не может освободить пространство, которое по-прежнему требуется для снимков; Таким образом, наличие большого количества моментальных снимков может привести к низкому эффективному коэффициенту сжатия системы. Однако моментальные снимки полезны для восстановления после сбоев. Не стоит сомневаться в необходимости создания снимков файловой системы или настройки соответствующих расписаний создания снимков файловой системы.
DDOS выполняет дедупликацию на лету по мере записи данных в систему. Он отслеживает влияние дедупликации на лету и локального сжатия для каждой операции записи и накапливает статистику на уровне файла. Статистика сжатия на лету для каждого файла дополнительно агрегируется на уровне mtree и на уровне системы. Сжатие измеряется на основе трех чисел во встроенной статистике:
Основываясь на трех приведенных выше числах, DDOS определяет еще два коэффициента сжатия с высокой степенью детализации:
Накопленная текущая статистика сжатия является частью метаданных файла в DDOS и хранится в индексном дескрипторе файла. DDOS предоставляет инструменты для проверки сжатия на всех трех уровнях; файловых, MTree и общесистемных. Мы подробно расскажем о них в следующих разделах.
3.1 Сжатие
файлов Сжатие файлов можно проверить с помощью CLI-команды «filesys show compression <path>», которая сообщает накопленную статистику сжатия, хранящуюся в индексном дескрипторе файла. Если указан каталог, то статистика сжатия всех файлов в этом каталоге суммируется и выводится в отчет. В выходных данных интерфейса командной строки raw_bytes помечен как «Original Bytes»; pre_lc_size помечен как «Глобальное сжатие»; post_lc_bytes помечен как «Локальное сжатие»; остальные накладные расходы указываются как «Метаданные». Два примера взяты из фактического 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 как «байт/storage_used». Тем не менее, следует проявлять осторожность при интерпретации вышеуказанной информации, поскольку она может ввести в заблуждение по различным причинам. Одна из причин заключается в том, что значения pre_lc_size и post_lc_size записываются во время обработки операций с данными. При удалении файла, в который изначально были добавлены эти сегменты, количество уникальных сегментов данных в оставшемся файле должно быть увеличено.
В качестве примера предположим, что резервная копия файла sample.file создается в Data Domain, и при первом резервном копировании информация о сжатии файла составляет pre_lc_size=10 ГиБ, post_lc_size=5 ГиБ.
Затем предположим, что данные этого файла уникальны и не передаются другим файлам. При втором резервном копировании файла предположим, что файл получает идеальную дедупликацию, так что pre_lc_size и post_lc_size должны быть равны нулю, поскольку все сегменты файла уже существовали в системе. При удалении первой резервной копии вторая резервная копия файла становится единственным файлом, который ссылается на сегменты данных размером 5 ГиБ. В этом случае в идеале pre_lc_size и post_lc_size файла во второй резервной копии должны быть обновлены с нуля до 10 ГиБ и 5 ГиБ соответственно. Однако невозможно определить, для каких файлов это должно быть сделано, поэтому встроенная статистика сжатия существующих файлов остается неизменной.
Еще одним фактором, влияющим на вышеуказанные цифры, является кумулятивная статистика. Когда файл получает много перезаписей, невозможно отследить, в какой степени кумулятивная статистика отражает записи, которые привели к появлению оперативных данных. Таким образом, в течение длительного времени встроенная статистика сжатия может рассматриваться только как эвристика для грубой оценки сжатия конкретного файла.
Еще один факт, который стоит отметить, заключается в том, что сжатие файла на лету не может быть измерено для произвольного интервала времени. Статистика сжатия файлов на лету представляет собой совокупный результат и охватывает все операции записи, которые когда-либо получал файл. Когда файл получает много перезаписей, raw_bytes может быть намного больше логического размера файла. Для разреженных файлов размеры файлов могут превышать значения исходных байтов.
3.2 Сжатие
MTreeМы можем проверить сжатие конкретного mtree с помощью метода "mtree show compression" (МСК) CLI-команда. Абсолютные значения встроенной статистики сжатия накапливаются за все время существования MTree. Учитывая, что время жизни MTree может составлять много лет, эти значения со временем становятся все менее и менее информативными. Для решения этой проблемы мы используем величину изменения (дельты) встроенной статистики сжатия и сообщаем о сжатии только за определенные интервалы времени. Основной подход заключается в том, что мы периодически выгружаем статистику сжатия MTree на лету в журнал. Когда клиент запрашивает сжатие MTree с помощью команды MSC, мы используем журнал для вычисления разницы чисел для отчетов о сжатии. По умолчанию 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 Гбайт логических данных.
MSC поддерживает параметры «daily» и «daily-detailed», а также команду «filesys show compression». Если указано значение "daily", команда сообщает о ежедневном сжатии в календарном режиме. Для расчета ежедневного коэффициента сжатия используются ежедневные дельта-значения raw_bytes и post_lc_size. Если указан параметр "daily-detailed", команда показывает все три дельты (raw_bytes, pre_lc_size и post_lc_size соответственно) для каждого дня; Он также вычисляет g_comp и l_comp наряду с общим коэффициентом сжатия.
Примеры выходных данных этих систем приведены в Приложении.
3.3 Сжатие
системы Как только мы поймем, как сжатие сообщается в MTree, можно будет легко распространить эту концепцию на всю систему. Сбор встроенной статистики и создание отчетов по сжатию в масштабах всей системы точно такие же, как и в MTree. Единственное различие заключается в области видимости, так как один находится в конкретном MTree, а другой — во всей системе. Результаты можно проверить с помощью команды «filesys show compression». Пример можно найти в разделе 2. Сжатие системы за последние 7 дней и за последние 24 часа отображается в последних двух строках раздела результатов в выходных данных FSC.
В DD с облачным уровнем хранилище разделено на активный и облачный уровни, которые являются двумя независимыми доменами дедупликации. Пользователи могут передавать данные только на активный уровень. Позже для переноса данных с активного уровня на облачный можно использовать функции перемещения данных DDOS. Таким образом, измерение пространства и сжатия, а также отчетность обрабатываются независимо на каждом уровне. Но на уровне файлов мы не делаем различий по уровням и не сообщаем статистику сжатия на лету; они в точности совпадают с тем, что мы описали в разделе 3.1.
Последняя тема, которую следует осветить, — это некоторые характеристики дедупликации, которая во многих документах Data Domain называется «глобальным сжатием». Несмотря на то, что он содержит слово «сжатие», оно полностью отличается от традиционной концепции сжатия, которая также предоставляется в DDOS под названием «локальное сжатие».
Локальное сжатие уменьшает размер фрагмента данных с помощью определенного алгоритма (некоторые типы данных не поддаются сжатию, и применение алгоритмов сжатия к ним может немного увеличить размер данных). Обычно, после того, как алгоритм определен, сами данные являются единственным фактором коэффициента сжатия.
Однако дедупликация отличается – это не локальное понятие, а «глобальное». Входящий сегмент данных дедуплицируется относительно всех существующих сегментов данных в дедуплицированном домене, который включает все данные в необлачных системах Data Domain. Сам сегмент данных в процедуре дедупликации значения не имеет.
На практике мы редко видим высокий коэффициент дедупликации при первоначальном резервном копировании набора данных. При первоначальном резервном копировании часто значительное сокращение объема данных происходит за счет локального сжатия. Когда последующие резервные копии попадают в Data Domain, дедупликация демонстрирует свои преимущества и становится доминирующим фактором для сжатия. Эффективность дедупликации зависит от того факта, что скорость изменения набора данных от резервной копии к резервной копии невелика. По этой причине наборы данных с высокой частотой изменений не могут быть хорошо дедуплицированы. Когда приложение резервного копирования с высокой частотой вставляет в образы резервных копий собственные блоки метаданных (называемые в Data Domain маркерами), коэффициент дедупликации также может быть недостаточным. Наши методы работы с маркерами могут помочь иногда, но не всегда.
Учитывая эти наблюдения, чего мы можем ожидать?
Измерить сжатие сложно в дедуплицированных файловых системах, но еще сложнее в дедуплицированных файловых системах со структурированными журналами. Мы должны понимать, как работает дедупликация и как отслеживается статистика сжатия. Коэффициенты сжатия — это полезная информация для понимания поведения конкретной системы. Эффективная степень сжатия системы является наиболее важным, надежным и информативным показателем. Статистика сжатия на лету также может быть полезна, но в некоторых случаях она может быть не более чем эвристикой.
Приложение: Пример выходных данных "mtree show compression" команда
Предположим, что существует MTree, содержащее 254792,4 ГиБ данных. Он получил 4379,3 ГиБ новых данных за последние 7 дней и 78,4 ГиБ за последние 24 часа (можно указать другие временные интервалы). Параметр «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