Методи стиснення, задіяні в домені даних, використовують найсучасніші методи для зменшення фізичного простору, необхідного для даних клієнта. Таким чином, технології та вимірювання рівнів стиснення є складними темами. У цьому документі обговорюються деякі термінології, компроміси та заходи, щоб краще пояснити використовувані типи стиснення, термінологію та інші аспекти стиснення в системі домену даних.
ЗАСТОСОВУЄТЬСЯ ДО:
Усі моделі доменів даних
Останнє оновлення: Січень 2024
р. Стиснення — це технологія скорочення даних, яка спрямована на зберігання набору даних, використовуючи менше фізичного простору. У системах Data Domain (DDOS) ми робимо дедуплікацію та локальне стиснення для стиснення даних користувача. Видалення дублікатів (dedupe) використовується для виявлення надлишкових сегментів даних і зберігання лише унікальних сегментів даних. Локальне стиснення додатково стискає унікальні сегменти даних за допомогою певних алгоритмів стиснення, таких як lz, gzfast, gz, і так далі. Загальне стиснення даних користувача в DDOS є спільними зусиллями дедуплікації та локального стиснення. DDOS використовує «коефіцієнт стиснення» для вимірювання ефективності стиснення даних. Як правило, це відношення загального розміру даних користувача до загального розміру стиснених даних або розміру використаного фізичного простору.
Файлова система Data Domain — це файлова система дедуплікації зі структурою журналу. Файлова система зі структурою журналу лише додає дані до системи, і видалення саме по собі не може звільнити фізичний простір. Такі файлові системи покладаються на збір сміття, щоб звільнити більше не потрібний простір. Характеристики файлової системи зі структурою журналу та технології дедуплікації разом ускладнюють чітке розуміння всіх аспектів стиснення в DDOS.
Для стиснення є багато аспектів, які ми можемо виміряти. У цьому документі ми крок за кроком обговорюємо деталі, які допоможуть зрозуміти стиснення DDOS. Спочатку ми пояснимо загальний ефект стиснення системи, який говорить нам про реалістичне стиснення, досягнуте в системі Data Domain, обсяг даних користувача, обсяг споживаного фізичного простору та їх співвідношення. Цей коефіцієнт у цьому документі називається «коефіцієнт системного стиснення». DDOS проводить дедуплікацію в режимі реального часу та відстежує статистику вихідних сегментів даних користувачів, сегментів унікальних даних після дедуплікації та ефект локального стиснення унікальних сегментів даних. Ця статистика вбудованого стиснення використовується для вимірювання ефекту вбудованого стиснення. Статистика вбудованого стиснення може бути виміряна для кожного запису. Також DDOS відстежує статистику на різних рівнях; файлів, MTrees і всієї системи.
Зміст цього документа можна застосувати до всіх випусків DDOS до публікації цього документа, аж до DDOS 7.13. Немає гарантії, що весь вміст є точним для майбутніх випусків. У випусках до версії 5.0 вся система має лише одне mtree, і термін mtree явно не називається.
Загальносистемний загальний ефект стиснення вимірюється ефективним коефіцієнтом стиснення системи, який є відношенням розміру даних користувача до розміру використовуваного фізичного простору. Про це повідомляє команда командного рядка файлового шоу стиснення (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 розділу результату у виводі CLI. Рядок виділений вище. Загальний розмір даних користувача позначається як "Pre-Comp". Загальний споживаний фізичний простір (як за даними, так і за метаданими) позначається як «Post-Comp».
Номер "Pre-Comp" і номер "Post-Comp" зчитуються під час виконання. FSC неявно синхронізує всю систему, а потім запитує два числа. Ці два числа вимірюються так само, як і команда
«fileys show space».Ефективний коефіцієнт стиснення системи = Pre-Comp/Post-Comp
Решта виводу FSC описує вбудовану статистику стиснення, і ми обговоримо її пізніше.
Є деякі операції, які можуть вплинути на ефективну ступінь стиснення системи:
Швидке копіювання
Коли fastcopy виконується з файла в активному просторі назв (не знімок), це ідеальна дедуплікація, оскільки для цільового файлу не потрібен додатковий фізичний простір. Ефект fastcopy полягає в тому, що ми збільшуємо розмір даних користувача, не займаючи додаткового фізичного простору. Це збільшує ефективний ступінь стиснення системи. Коли робиться багато швидких копій, ефективний ступінь стиснення системи може стати штучно високою.
Віртуальна синтетика
Віртуальні синтетичні резервні копії, як правило, демонструють високий коефіцієнт стиснення системи. Це пов'язано з тим, що віртуальна синтетика робить логічні повні резервні копії, але тільки передає змінені або нові дані в системи Data Domain. Вплив на ефективну систему ступеня стиснення віртуальної синтетики чимось схожий на ефект fastcopy.
Перезапис
Перезапис займає більше фізичного простору, але не збільшує логічний розмір набору даних, а отже, перезапис знижує ефективний коефіцієнт стиснення системи.
Зберігання розріджених файлів
Розріджені файли містять великі «дірки», які враховуються в логічному розмірі, але не займають фізичного простору через стиснення. В результаті вони можуть зробити ефективний ступінь стиснення системи високою.
Зберігання невеликих файлів
DDOS додає майже 1 КБ накладних витрат до кожного файлу для певних внутрішніх метаданих. Коли система зберігає значну кількість малих файлів (розміром менше 1 КБ або в однозначних кілобайтах), накладні витрати на метадані знижують ефективний коефіцієнт стискання.
Зберігання попередньо стиснутих або попередньо зашифрованих файлів
Стиснення та шифрування можуть посилити рівень зміни даних і зменшити можливість дедуплікації. Такі файли, як правило, не можуть бути добре дедупліковані та знижують ефективний коефіцієнт стиснення системи.
Видаляє
Видалення зменшують логічний розмір системи, але система не отримує назад відповідний невикористаний простір, доки не запуститься збір сміття. У багатьох видалених файлах коефіцієнт стиснення низький, доки не запуститься збір сміття (GC).
Збір сміття (GC) або прибирання
GC відвойовує простір, зайнятий сегментами даних, які більше не відображаються жодним файлом. Якщо останнім часом було видалено багато файлів, GC може збільшити ступінь стиснення системи, зменшивши фізичне споживання простору.
Агресивна зйомка знімків
Коли ми робимо знімок Mtree, ми не змінюємо логічний розмір набору даних. Однак усі сегменти даних, на які посилається знімок, мають бути заблоковані, навіть якщо всі файли, захоплені знімком, буде видалено після його створення. GC не може повернути простір, який все ще потрібен для знімків; Тому наявність великої кількості знімків може призвести до того, що ефективний ступінь стиснення системи може здатися низькою. Однак знімки є корисними засобами відновлення після збоїв. Ми ніколи не повинні соромитися робити знімки або встановлювати правильні графіки знімків, коли це необхідно.
DDOS проводить дедуплікацію вбудовано, оскільки дані записуються в систему. Він відстежує ефекти вбудованої дедуплікації та локального стиснення для кожного запису, а також накопичує статистику на рівні файлу. Статистика вбудованого стиснення для кожного файла додатково узагальнюється на рівні mtree та на рівні системи. Стиснення вимірюється на основі трьох чисел у вбудованій статистиці:
Ґрунтуючись на наведених вище трьох числах, DDOS визначає ще два коефіцієнти стиснення дрібної деталізації:
Накопичена вбудована статистика стиснення є частиною метаданих файлу в DDOS і зберігається у файловому inode. DDOS надає інструменти для перевірки вбудованих стиснень на всіх трьох рівнях; file, MTree та загальносистемний. Ми детально розглянемо їх у наступних розділах.
3.1 Стиснення
файлів Стиснення файлів можна перевірити за допомогою команди CLI "fileys show <compression path>", яка повідомляє накопичену статистику стиснення, що зберігається у файловому inode. Коли вказано каталог, буде підсумовано і повідомлено вбудовану статистику стискання всіх файлів у цьому каталозі. У виводі CLI raw_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 має резервну копію в домен даних, і в першій резервній копії інформація про стиснення файлу становить pre_lc_size=10GiB, post_lc_size=5Gib.
Далі припустімо, що дані цього файлу є унікальними і не мають спільного використання даних з будь-яким іншим файлом. У другій резервній копії файла далі припустімо, що файл отримує ідеальну дедуплікацію, таку, що і pre_lc_size, і post_lc_size мають дорівнювати нулю, оскільки всі сегменти файлу вже існували в системі. Коли перша резервна копія видаляється, друга резервна копія файлу стає єдиним файлом, який посилається на 5 Гб сегментів даних. У цьому випадку, в ідеалі, pre_lc_size і post_lc_size файлу в другій резервній копії повинні бути оновлені з нуля до 10 Гб і 5 Гб відповідно. Втім, немає способу визначити, для яких файлів це слід зробити, тому вбудовану статистику стискання наявних файлів залишено незмінною.
Ще одним фактором, який впливає на наведені вище цифри, є кумулятивна статистика. Коли файл отримує багато перезаписів, неможливо відстежити, якою мірою сукупна статистика відображає записи, які ввели живі дані. Таким чином, протягом тривалого часу статистику вбудованого стиснення можна розглядати лише як евристику для приблизної оцінки стиснення певного файла.
Ще одним фактом, на який варто звернути увагу, є те, що вбудоване стиснення файлу не може бути виміряне за довільний інтервал часу. Статистика вбудованого стиснення файлу є кумулятивним результатом і охоплює всі записи, які коли-небудь отримував файл. Коли файл отримує багато перезаписів, raw_bytes може бути набагато більшим за логічний розмір файлу. Для розріджених файлів розміри файлів можуть бути більшими, ніж «Оригінальні байти».
3.2 Стиснення MTree Ми
можемо перевірити стиснення конкретного mtree за допомогою кнопки "mtree show compression" (MSC) Команда CLI. Абсолютні значення вбудованої статистики стиснення є кумулятивними протягом усього терміну служби MTree. Враховуючи, що термін служби MTree може тривати багато років, з часом ці значення стають все менш інформативними. Щоб вирішити цю проблему, ми використовуємо величину зміни (дельти) вбудованої статистики стиснення та повідомляємо про стискання лише за певні проміжки часу. Базовий підхід полягає в тому, що ми періодично скидаємо статистику вбудованого стиснення MTree до журналу. Коли клієнт запитує стиснення MTree за допомогою команди MSC, ми використовуємо log для обчислення дельт чисел для звітів про стиснення. За замовчуванням 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», а також команду «fileys show compression». Якщо вказано "daily", команда повідомляє про щоденне стискання у календарному порядку. Він використовує добові дельти raw_bytes і post_lc_size для обчислення добового коефіцієнта стиснення. Якщо вказано «щоденно-детальний», команда показує всі три дельти (raw_bytes, pre_lc_size та post_lc_size відповідно) для кожного дня; Він також обчислює g_comp і l_comp разом із загальним коефіцієнтом стиснення.
Вибіркові дані з цих систем наведені в Додатку.
3.3 Стиснення
системи Після того, як ми зрозуміємо, як повідомляється про стиснення на MTrees, легко поширити цю концепцію на всю систему. Вбудована статистика стиснення та звітування на рівні системи точно така сама, як і у MTrees. Єдиною відмінністю є область видимості, оскільки один знаходиться в конкретному MTree, а інший - у всій системі. Результати можна перевірити за допомогою команди "fileys show compression". Приклад цього можна знайти в розділі 2. Системне стиснення «останні 7 днів» і «останні 24 години» повідомляється в останніх двох рядках розділу результатів у виводі FSC.
На DD з реалізованим хмарним рівнем сховище розділяється на активний і хмарний рівні, які є двома незалежними доменами дедуплікації. Користувачі можуть вставляти дані лише в активний рівень. Пізніше функції переміщення даних DDOS можуть бути використані для міграції даних з активного рівня на рівень хмари. Таким чином, вимірювання простору та стиснення, а також звітність обробляються незалежно на кожному рівні. Але на рівні файлу ми не диференціюємо за рівнями та не повідомляємо статистику вбудованого стиснення; вони точно такі ж, як і ті, що ми описали в розділі 3.1.
Останньою темою, на яку слід звернути увагу, є деякі характеристики дедуплікації, яка в багатьох документах Data Domain називається «глобальним стисненням». Незважаючи на те, що він містить слово «стиснення», воно повністю відрізняється від традиційної концепції стиснення, яка також надається DDOS під назвою «локальне стиснення».
Локальне стиснення зменшує розмір фрагмента даних за допомогою певного алгоритму (деякі види даних не піддаються стисненню і застосування до них алгоритмів стиснення може дещо збільшити розмір даних). Зазвичай, після того, як алгоритм визначений, самі дані є єдиним фактором ступеня стиснення.
Однак дедуплікація відрізняється - це не локальне поняття, воно «глобальне». Сегмент вхідних даних дедуплюється з усіма наявними сегментами даних у дедуплікованому домені, який включає всі дані в системах нехмарних доменів даних. Сам сегмент даних не має значення в процедурі дедуплікації.
На практиці ми рідко бачимо високий коефіцієнт дедуплікації при первинному резервному копіюванні набору даних. При початковому резервному копіюванні часто основне скорочення даних відбувається за рахунок локального стиснення. Коли наступні резервні копії потрапляють у домен даних, дедуплікація показує свою силу та стає домінуючим фактором для стиснення. Ефективність дедуплікації ґрунтується на тому, що швидкість зміни набору даних від резервного копіювання до резервного копіювання низька. З цієї причини набори даних з високою швидкістю змін не можуть бути добре дедуповані. Коли програма резервного копіювання вставляє власні фрагменти метаданих (які називаються маркерами домену даних) у резервні копії образів із високою частотою, вона також може не отримати належного коефіцієнта дедуплікації. Наші методи поводження з маркерами іноді можуть допомогти, але не завжди.
З огляду на ці спостереження, чого ми можемо очікувати?
Виміряти стиснення складно в дедуплікованих файлових системах, але ще складніше в дедуплікованих файлових системах зі структурою журналів. Ми повинні розуміти, як працює дедуплікація і як відстежується статистика стиснення. Коефіцієнти стиснення є корисною інформацією для розуміння поведінки конкретної системи. Ефективний ступінь стиснення системи є найважливішим, надійним та інформативним показником. Вбудована статистика стискання також може бути корисною, але за деяких обставин вона може бути не більше ніж евристикою.
Додаток: Приклад вихідних даних "mtree show compression"
команда Припустимо, що існує MTree, що містить 254792,4 ГіБ даних. За останні 7 днів він отримав 4379,3 ГіБ нових даних, а за останні 24 години – 78,4 Гіб (можна вказати інші часові проміжки). Параметр «щодня» повідомляє статистику вбудованого стиснення за останні 33 дні. Якщо передбачено параметр «щоденна деталізація», загальний коефіцієнт стиснення деталізується шляхом поділу його на глобальний і локальний коефіцієнти стиснення.
Виведення списку 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