Домен даних : Розмір, який можна очистити, є приблизним

Часто виникає плутанина щодо значення «GiB, що очищається», представленого в системі Data Domain, і неправильні очікування щодо обсягу простору, який буде відновлено після запуску очищення.

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

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

Коли дані приймаються системою Data Domain, значення після стиснення обчислюється та зберігається як статичні дані для кожного файлу. Значення "Cleanable" - це просто сума значень після стиснення для всіх видалених файлів з моменту останнього запуску DD clean до завершення.
 

Значення «Придатне для очищення» стає неточним, якщо сегменти файлів для видалених файлів використовувалися для видалення дедуплікації даних в інших файлах, які не були видалені. Доки існує один файл, що посилається на існуючий унікальний сегмент, процес очищення DD не розглядатиме ці сегменти для відновлення. Таким чином, навіть якщо пост-комп'ютер файлу був доданий в лічильник "Cleanable GiB" так, ніби всі його унікальні сегменти збираються викинути, деякі (або багато) можуть цього не зробити через повторне використання іншими файлами.
 

Нижче наведено більш детальний приклад, що демонструє цей ефект:

Припустимо, що у вас є 5 файлів, доданих один за одним до системи Data Domain, без будь-яких інших даних на ньому.

Оскільки перші 100 ГБ файлів містили всі унікальні дані, коефіцієнт стиснення становить 1x (за умови, що перший файл не мав зайвості в самому файлі). 2-5-й файли були здатні дедуплювати дані 1-го файлу та кожен зі старих файлів у міру їх додавання, кожен з яких отримує все більше дублювання через збільшення файлів, щодо яких потрібно видалити дублікати.

File 1: precomp: 100 GB postcomp: 100 GB compression ratio: 1x
File 2: precomp: 100 GB postcomp:  50 GB compression ratio: 2x
File 3: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 4: precomp: 100 GB postcomp:  25 GB compression ratio: 4x
File 5: precomp: 100 GB postcomp:   1 GB compression ratio: 100x

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         500           -      -                -
/backup: post-comp      1000         201         799    20%                0
----------------   ---------   ---------   ---------   ----   --------------

Приклад 1. Статус після видалення перших 3 файлів з /backup :
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         200           -      -                -
/backup: post-comp      1000         201         799    20%              175
----------------   ---------   ---------   ---------   ----   --------------

Якщо після цього ви запустите функцію очищення, ви можете повернути 125 замість повних 175, які можна очистити. Це пов'язано з тим, що останні 2 файли ділять сегменти з файлами 1-3.  Очищення не відновить інші 50 ГБ простору, оскільки ці сегменти все ще використовуються файлами 3-5.
 

Приклад 2: Використовуючи ту ж початкову точку, що і в прикладі 1, припустимо, що файл 1 був видалений, потім швидка копія виконана на всій папці /backup (тобто всі 5 файлів), а потім видалення файлів 2-4. 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         201         799    20%              200
----------------   ---------   ---------   ---------   ----   --------------

Показник "Розмір GiB" для pre-comp виходить з (500-100)=400*2=800, що дає 500 для 5 оригінальних файлів, віднімання 100 для видалення файлу 1 дає 400 GiB.  Далі 400 ГіБ, помножені на 2 за рахунок fastcopy на всіх 4 файлах, що залишилися.

Зауважте, що використаний простір після комп'ютера залишається незмінним, оскільки копія файлу додає лише невелику кількість простору, що складається з посилань на метадані вихідні дані. Використання простору не змінилося, незважаючи на видалення Файлу 1, оскільки не було запущено "чистий старт файлу" (щоб ініціювати очищення). 
 

Після Чистки ми побачимо:
 

Resource            Size GiB    Used GiB   Avail GiB   Use%   Cleanable GiB*
----------------   ---------   ---------   ---------   ----   --------------
/backup: pre-comp          -         800           -      -                -
/backup: post-comp      1000         176         824    18%                0
----------------   ---------   ---------   ---------   ----   --------------

Зверніть увагу, що хоча 200 ГБ було показано як придатне для очищення, насправді було очищено лише 25 ГБ. "Cleanable GiB" показав як 200, оскільки розмір файлу "post-comp" файлів з 1 по 4 склав до 200 ГБ.  Було видалено лише "Файл 1", який становив 100 ГБ, але 75 ГБ з яких все ще використовувалися іншими 4 файлами (через видалення дублікатів).  

Це може здатися дивним, оскільки "Файл 2" - "Файл 4" також були видалені, але пам'ятайте, що хоча система показує "Файл 2" - "Файл 4" як видалені, фактичні сегменти даних для цих файлів не можуть бути видалені, оскільки ці файли були швидко скопійовані в іншу папку.   Тільки після того, як всі версії fastcopy також були видалені, можна повністю відновити простір шляхом очищення.

Оскільки чистий GiB є лише «приблизним» і може бути неточним, навіть іноді він може відображати великий або такий же розмір, як фізична ємність Data Domain.

Це може призвести до плутанини, чи дозволяти запуск запланованого очищення DDFS або вручну, якщо використання простору DDFS наближається до 100% через те, що GiB, що очищається, відображається поруч або має таке ж значення, як "/data: post-comp".

Щоб мати кращий і надійніший спосіб оцінки кількості чистого дискового простору, який буде зайнято під час роботи, починаючи з DDOS 7.7.x, тепер можна визначити за CLI фактичний «Total Cleanable-Space», який наступний GC на активному рівні зможе відшкодувати. Ось короткий виклад CLI :
 

# filesys cleanable-space calculate
Cleanable space calculation started. Use 'filesys cleanable-space watch' to monitor progress.

Процес буде робити те ж саме, що і звичайний GC, проходячи фази з 1 по 4, але пропускаючи фазу 5 (копіювання), яка ефективно копіює прямі контейнери, щоб звільнити мертвий дисковий простір. Таким чином, знадобиться стільки часу, скільки потрібно звичайному GC для завершення чистих фаз з 1 по 4, щоб повернути значення, тому це не те, що потрібно запускати регулярно для отримання оновленої оцінки, а лише за необхідності. Іншими словами, "fileys cleanable-space calculate" запустить GC на рівні Active, просто пропускаючи частину, в якій він звільняє місце.

Процес можна контролювати наступним чином:
 

# filesys cleanable-space watch
Beginning 'filesys cleanable-space calculation' monitoring.  Use Control-C to stop monitoring.

Cleaning: phase 1 of 4 (pre-merge)
  100.0% complete, 96233 GiB free; time: phase  0:02:07, total  0:02:07

Cleaning: phase 2 of 4 (pre-analysis)
  100.0% complete, 96233 GiB free; time: phase  0:06:51, total  0:08:59

Cleaning: phase 3 of 4 (pre-enumeration)
  100.0% complete, 96233 GiB free; time: phase  0:00:20, total  0:09:20

Cleaning: phase 4 of 4 (pre-select)
  100.0% complete, 96233 GiB free; time: phase  0:00:25, total  0:09:46

Після завершення можна отримати доступ до чистого результату вимірювання:

# filesys cleanable-space status

Cleanable space on active tier is 94649698202 bytes. Last calculated on 2023/08/25 03:29:51
Cleanable space calculation finished at 2023/08/25 03:29:51.

Отже, у наведеному вище прикладі тесту, якщо DD GC має бути запущений зараз, то він звільнить 94649698202 байти. Це 88,1 ГіБ, тоді як на момент розрахунку оцінка, про яку повідомляв «df» у лабораторії, яку використовував DD, становила 41,9 ГіБ. Звичайно, у міру внесення змін до ФС (нові резервні копії, більше видалень, створюються та закінчуються знімки тощо) розрахунок піде.

Якщо потрібно, щоб зупинити вищевказаний процес, можна використовувати команду нижче:

# filesys cleanable-space stop

The 'filesys cleanable-space stop' command stops calculating cleanable space in the system.
Are you sure? (yes|no) [no]: yes

ok, proceeding.

# filesys cleanable-space status
Cleanable space on active tier is 2607064 bytes. Last calculated on 2021/06/27 23:23:05
Cleanable space calculation started at 2021/06/27 23:27:58 and was aborted at 2021/06/27 23:28:19.
Cleaning was aborted by user.

Зверніть увагу, що цей CLI застосовується лише до рівня DD Active. Не існує еквівалентного процесу для обчислення придатного для очищення хмарного блоку DD, який має власну оцінку з урахуванням тих самих невизначеностей, що описані вище.