Домен даних: Розуміння стиснення домену даних

Техніки стиснення, застосовані в домені даних, використовують найсучасніші методи для зменшення фізичного простору, необхідного для резервного копіювання даних. Тому технології та вимірювання рівнів стиснення є складними темами.

У цій статті розглядаються деякі термінології, компроміси та заходи для кращого пояснення типу стиснення, який використовується, а також інші аспекти стиснення в середовищі домену даних.

ЗАСТОСОВУЄТЬСЯ ДО: Усі моделі домену даних

Вступ:

Останнє оновлення: Січень 2024

• Стиснення — це технологія зменшення даних, яка має на меті зберігати набір даних із меншим фізичним простором.
• У системах домену даних (DDOS) дедуплікація та локальне стиснення виконуються для стиснення користувацьких даних. Дедуплікація, або «дедуп», використовується для ідентифікації надлишкових сегментів даних і зберігання лише унікальних сегментів даних.
• Локальне стиснення додатково стискає унікальні сегменти даних за допомогою певних алгоритмів стиснення, таких як lz, gzfast, gzі так далі.
• Загальне стиснення користувацьких даних у DDOS — це спільна робота дедуплікації та локального стиснення. DDOS використовує «ступінь стиснення» для вимірювання ефективності стиснення даних.
• Зазвичай це відношення загального розміру даних користувача до загального розміру стиснених даних або розміру використаного фізичного простору.
• Файлова система домену даних — це файлова система дедуплікації з «лог-структурою».
• Файлова система з логарифмічною структурою лише додає дані до системи, і саме видалення не може звільнити фізичний простір.
• Такі файлові системи покладаються на збір сміття, щоб повернути вже непотрібний простір.
• Характеристики лог-структурованої файлової системи та технології дедуплікації разом ускладнюють чітке розуміння всіх аспектів стиснення в DDOS.

Для стиснення існує багато аспектів, які можна виміряти.

У цій статті розглядаються покрокові деталі для розуміння стиснення DDOS.

• Спочатку пояснюється загальний ефект стиснення системи, який показує реалістичне стиснення, досягнуте в системі домену даних, кількість користувацьких даних, обсяг фізичного простору, що споживається, та їхнє співвідношення.
• У цій статті це співвідношення називається «ефективним коефіцієнтом стиснення системи».
• DDOS проводить дедуплікацію в лінії та відстежує статистику оригінальних сегментів користувацьких даних, унікальних сегментів даних після дедупування та локальний ефект стиснення унікальних сегментів даних.
• Ці статистики стиснення в ряді використовуються для вимірювання ефекту внутрішнього стиснення. Статистика внутрішнього стиснення може вимірюватися для кожного запису. Також DDOS відстежує статистику на різних рівнях: Файли, MTrees, і всю систему.

Немає гарантії, що весь зміст буде достовірним для майбутніх релізів.

У версіях до версії 5.0 вся система має лише один mtree і термін 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.

• •  
  • Ефективний коефіцієнт стиснення системи вказується у рядку 1 розділу результату у вихідному записі CLI. Рядок виділено вище.
  • Загальний розмір користувацьких даних позначається як «Pre-Comp».
  • Загальний фізичний простір, який використовується (як за даними, так і за метаданими) позначається як «Post-Comp».
  • Номер «Pre-Comp» і «Post-Comp» читаються під час виконання. FSC неявно синхронізує всю систему, а потім робить запит до двох чисел.
    • Ці два числа вимірюються так само, як і "filesys show space" Командування.
    • Ефективний коефіцієнт стиснення системи = Pre-Comp/Post-Comp

Існують операції, які можуть впливати на ефективну здатність стиснення системи:

• Швидка копія
  • Коли fastcopy виконується з файлу в активному просторі імен (не знімку), це ідеальне дедуплікація, оскільки для цільового файлу не потрібен додатковий фізичний простір. Вплив fastcopy полягає в тому, що розмір даних користувача збільшується без додаткового фізичного простору. Це підвищує ефективне коефіцієнт стиснення системи. Коли багато fastcopies Після завершення ефективний коефіцієнт стиснення системи може штучно підвищитися.
• Віртуальна синтетика
  • Віртуальні синтетичні резервні копії зазвичай демонструють високий ефективний коефіцієнт стиснення системи. Це пов'язано з тим, що віртуальні синтетичні системи роблять логічні повні резервні копії, але лише передають змінені або нові дані до систем домену даних. Вплив віртуальної синтетики на ефективний коефіцієнт стиснення дещо подібний до ефекту fastcopy.
• Перезаписи
  • Перезаписи займають більше фізичного простору, але не збільшують логічний розмір набору даних, тому перезаписують знижує ефективний коефіцієнт стиснення системи
• Зберігання розріджених файлів
  • Розріджені файли містять великі «дірки», які враховуються у логічному розмірі, але не займають фізичний простір через стиснення. Внаслідок цього вони можуть зробити ефективний ступінь стиснення системи високим.
• Зберігання малих файлів
  • DDOS додає майже 1 КБ накладних витрат до кожного файлу для певних внутрішніх метаданих. Коли система зберігає значну кількість малих файлів (розміром менше 1 КБ або в однозначних кілобайтах), накладні витрати на метадані зменшують ефективне коефіцієнт стиснення.
• Зберігання попередньо стиснених або попередньо зашифрованих файлів
  • Стиснення та шифрування можуть посилити рівень змін даних і зменшити ймовірність дедуплікації. Такі файли зазвичай не можна добре дедуплікувати, що знижує ефективний коефіцієнт стиснення системи.
• Видаляє
  • Видалення зменшує логічний розмір системи, але система не повертає відповідний невикористаний простір, доки не запуститься збір сміття. Багато видалених файлів знижують коефіцієнт стиснення до запуску Garbage Collection (GC).
• Збір сміття (GC) або прибирання
  • GC повертає простір, зайнятий сегментами даних, які більше не видно жодним файлом. Якщо багато файлів було видалено нещодавно, GC може збільшити коефіцієнт стиснення системи, зменшуючи фізичне споживання простору.
• Агресивне зйомки
  • Коли знімок Mtree забирається, логічний розмір набору даних не змінюється. Однак усі сегменти даних, на які посилається знімок, мають бути заблоковані, навіть якщо всі файли, захоплені знімком, видаляються після його зйомки. GC не може відновити простір, який ще потрібен знімкам, велика кількість знімків може зробити ефективне коефіцієнт стиснення системи низьким. Однак знімки є корисними засобами відновлення після аварій. Ніколи не соромтеся робити знімки або налаштовувати правильні графіки знімків, коли це потрібно.

Компресія: Інлайн-статистика:

DDOS здійснює дедуплікацію в лінійному режимі, оскільки дані записуються в систему. Він відстежує ефекти вбудованої дедуплікації та локального стиснення для кожного запису, а також накопичує статистику на рівні файлу. Статистика внутрішнього стиснення для кожного файлу додатково агрегується на mtree на рівні та на рівні системи. Стиснення вимірюється за трьома числами в інлайн-статистиці:

• Довжина кожного запису: raw_bytes 
• The length of all unique segments: pre_lc_size
• Довжина локально стиснутих унікальних сегментів: post_lc_size

• • Глобальне стиснення (g_comp)
    • Дорівнює (raw_bytes/pre_lc_size), і відображає коефіцієнт дедуплікації
  • Локальне стиснення (l_comp)
    • Дорівнює (pre_lc_size/post_lc_size) і відображає ефект алгоритму локального стиснення

Накопичена статистика внутрішнього стиснення є частиною метаданих файлу в DDOS і зберігається у файлі inode. DDOS надає інструменти для перевірки вбудованих стиснень на всіх трьох рівнях; Файл, MTree, і по всій системі. Вони детально описані у наступних розділах.

Стиснення файлів:

• • Стиснення файлів можна перевірити за допомогою "filesys show compression <path>" команду CLI, яка повідомляє накопичену статистику стиснення, збережену у файлі 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 записуються під час обробки операцій з даними.
    • Коли файл, який спочатку додав ці сегменти, видаляється, кількість унікальних сегментів даних у решті файлу має бути збільшена.

Наприклад, припустимо, що зразок файлу резервно скопіюваний у домен даних, і в першій резервній копії інформація про стиснення файлу виглядає 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 може бути значно більшим за логічний розмір файлу. Для розріджених файлів розміри файлів можуть бути більшими за «Оригінальні байти».

Компресія MTree:

• • Стиснення певного mtree можна перевірити за допомогою "mtree show compression" (MSC) командування 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 GB логічних даних.

• • MSC Підтримує опції «щоденний» та «щоденний деталізований», як і »filesys show compression" Командування.
  • Коли вказано «daily», команда повідомляє щоденне стиснення у календарі.
  • Він використовує щоденні дельти raw_bytes та post_lc_size щоб обчислити добовий коефіцієнт стиснення.
  • Коли вказано «daily-detailed», команда показує всі три дельти (від raw_bytes, pre_lc_size, та post_lc_size, відповідно) для кожного дня. Він також обчислює g_comp та l_comp разом із загальним коефіцієнтом стиснення.

Зразок результатів цих систем наведено в додатку нижче.

Стиснення системи:

• • Як звітується про стиснення MTrees Зрозуміло, що дуже просто поширити концепцію на всю систему.
  • Збір і звітність статистики при стисненні в системі є абсолютно такими ж, як і у випадку MTrees.
  • Єдина різниця — це обсяг, оскільки людина перебуває в певному MTree, тоді як один охоплює всю систему.
  • Результати можна перевірити, використовуючи "filesys show compression" Командування.
  • Приклад цього можна знайти в Розділі 2.
  • Стиснення системи «останні 7 днів» та «останні 24 години» наведено в останніх двох рядках розділу результатів у FSC Вихід.

Хмарний рівень:

• У DD з реалізованим хмарним рівнем сховище розділяється на активний і хмарний рівні, які є двома незалежними доменами дедуплікації.
• Користувачі можуть вводити дані лише в активний рівень.
• Пізніше функції переміщення даних DDOS можуть використовуватися для міграції даних з активного рівня до хмарного рівня.
• Таким чином, вимірювання простору та стиснення та звітність здійснюється незалежно на кожному рівні.
• Але на рівні файлів не проводиться диференціація за рівнями та звітами статистики стиснення в рядку, вони точно такі ж, як описані в розділі 3.1.

Дедуплікація:

Остання тема, яку варто підкреслити, — це деякі характеристики дедуплікації, яку у багатьох статтях домену даних називають «глобальним стисненням».

Хоча воно містить слово «стиснення», воно повністю відрізняється від традиційного поняття стиснення, яке також використовується в DDOS під назвою «локальне стиснення».

• Локальне стиснення зменшує розмір фрагмента даних за допомогою певного алгоритму (деякі типи даних не є стисними, і застосування алгоритмів стиснення може трохи збільшити розмір даних).
• Зазвичай, після визначення алгоритму, дані є єдиним фактором ступеня стиснення.
• Однак дедуплікація відрізняється — це не локальне поняття, а «глобальне».
• Вхідний сегмент даних дедуплюється на всі існуючі сегменти даних у дедуплікованому домені, що включає всі дані з нехмарних систем домену даних.
• Сам сегмент даних не має значення у процесі дедуплікації.
• На практиці високий коефіцієнт дедуплікації рідко спостерігається при початковому резервному копії набору даних. У початкових резервних копіях часто основне скорочення даних відбувається за рахунок локального стиснення.
• Коли наступні резервні копії потрапляють у домен даних, дедуплікація демонструє свою силу і стає домінуючим фактором стиснення.
• Ефективність дедуплікації залежить від того, що швидкість змін набору даних від резервної копії до резервної копії низька. З цієї причини набори даних з високою частотою змін неможливо добре роздулювати.
• Коли резервний додаток вставляє власні фрагменти метаданих (які Data Domain називають маркерами) у резервні зображення з високою частотою, він також може не отримати хорошого співвідношення дедуплікації. Наші методи обробки маркерів іноді допомагають, але не завжди.

Враховуючи ці спостереження, чого очікувати:

• Початкові резервні копії можуть досягати лише невеликого ефективного коефіцієнта стиснення системи, часто 2x або 3x. Deduplicate зазвичай має мало можливостей проявити свою силу у початкових резервних копіях.
• Глобальний коефіцієнт стиснення інкрементального резервного копія нижчий за коефіцієнт стиснення відповідного повного резервного копіювання. Це пов'язано з тим, що інкрементальна резервна копія містить лише змінені або нові файли порівняно з безпосередньою попередньою резервною копією. Глобальний коефіцієнт стиснення залежить від відсотка нових даних у інкрементальному резервному копіюванні.
• Коефіцієнт дедуплікації повної резервної копії (непочаткових) також може бути низьким у деяких випадках. Деякі часто спостерігані сценарії:
  • Висока швидкість змін даних, які резервуються
  • Набір даних домінують невеликі файли (менше 5 МіБ)
  • Резервні додатки додають багато щільно розташованих маркерів
  • Резервні копії бази даних, які є інкрементальними або використовують малий розмір блоків
  • Коли спостерігається низький коефіцієнт стиснення у повному резервному копії з низькою швидкістю зміни даних, перевіряйте, чи застосовується один із наведених вище випадків, або чи потрібен додатковий аналіз.
• Стиснення пізнішого резервного образу не завжди краще, ніж початкове. Послідовні резервні зображення можуть демонструвати високий коефіцієнт дедуплікації, оскільки початкові та ранні резервні зображення вже додавали більшість даних до системи. Коли всі попередні образи резервної копії видаляються, глобальний і локальний коефіцієнт стиснення найранішого існуючого образу може залишатися високим, але це лише означає, що при додаванні до системи він отримав хорошу дедуплікацію, нічого більше. Коли видаляється файл із високим глобальним і локальним коефіцієнтом стиснення і останнім резервним зображенням певного набору даних, він може звільнити більше місця, ніж розмір, отриманий за коефіцієнтом стиснення.
• Коефіцієнти стиснення одного й того ж набору даних на різних системах не можна порівнювати, незалежно від способу додавання набору даних до цих систем. Це пов'язано з тим, що кожна система є незалежною областю дедуплікації. Не очікується, що два різні DD отримують однакові або навіть обов'язково схожі коефіцієнти стиснення, навіть якщо їхні набори даних однакові.

Резюме:

• Вимірювати стиснення складно у дедуплікованих файлових системах, але ще складніше у логарифм-структурованих дедуплікованих файлових системах.
• Потрібно розуміти, як працює дедуплікація та як відстежується статистика стиснення.
• Коефіцієнти стиснення — це корисна інформація для розуміння поведінки конкретної системи.
• Ефективний коефіцієнт стиснення системи є найважливішим, надійним і найінформативнішим показником.
• Статистика інлайн-компресії теж може бути корисною, але в деяких випадках вона може бути не більше ніж евристикою.

Додаток:

Вибірковий вихід "mtree show compression" Командування

• Припустимо, що існує MTree що містить 254792,4 ГіБ даних. За останні 7 днів вона отримала 4379,3 ГіБ нових даних і 78,4 ГіБ за останні 24 години (можна вказати й інші часові інтервали).
• Опція «щоденна» показує статистику стиснення за останні 33 дні.
• Коли надається опція «щоденно детальне», загальні ступені стиснення детальніше деталізуються шляхом розділення їх на глобальні та локальні ступені стиснення.

The 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

MSC (варіантів немає):

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