Программное обеспечение Data Domain: Расхождение между использованием, о котором сообщает «filesys show space (df)», и общими значениями sfs_dump

Цель команды «sfs_dump» (или filesys show compression) — помочь понять степень сжатия, достигнутую для файла во время приема. Он не предназначен для отражения общего занимаемого пространства.

Суммирование размера всех файлов после сжатия, указанное с помощью команды «sfs_dump», будет соответствовать общему использованию пространства, только если в файловой системе никогда не выполнялось удаление. В производственной DDR такого никогда не бывает, поэтому использование «sfs_dump» для учета текущего использования пространства является ошибочным. Мы проиллюстрируем это на примере ниже.
 
 
ИЛЛЮСТРАЦИЯ:
 
Это легко увидеть на простом трехступенчатом примере:
 

1.  Я делаю резервную копию файла (file1) размером 10 ГБ. Допустим, это совершенно новая коробка и нет ничего для дедупликации. Таким образом, размер после сжатия также составляет около 10 Гбит/с.

# sfs_dump /данные/col1/тест/ /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 размер: Тип 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%) режим: 02000100644

 
Как видно выше, размер после сжатия составляет 10 Гбайт.


         II.  Далее я делаю резервную копию еще одного файла размером 10 ГБ (file2).  Это очень похоже или то же самое, что и file1.   

# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 fileid: 18 размер: Тип 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (102%) режим: 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 размер: Тип 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Режим 0 (0%): 02000100644

 
Как было показано выше, file2 не занял дополнительного места, так как он полностью дедуплицировался с помощью file1.
 

          III.   Теперь я удаляю File1 и снова запускаю «sfs_dump» на mtree.  

# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 fileid: 19 размер: Тип 10736790004: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (100%) pre_lc_size: 0 post_lc_size: Режим 0 (0%): 02000100644

 
 
Исходя из вышеизложенного, заказчик может ожидать, что в файловой системе не будет занимать место.  Единственный файл в mtree занимает 0 байт после сжатия (суммирование всех файлов, о которых сообщает sfs_dump, равно 0 байт).  Но это заблуждение. Использование пространства в системе фактически составляет 10 Гбит/с и точно отражается df . 
 
Это связано с тем, что File2 ссылается на все сегменты, первоначально записанные File1.  Удаление File1 ничего не освободило. «sfs_dump» не показывает исходный файл File1, так как он был удален.

# дф Активный уровень: Размер ресурса Использованные ГиБ Доступные гиБ Использование % Очищаемые ГиБ* ---------------- -------- -------- --------- ---- -------------- /data: pre-comp - 10,0 - - - /data: post-comp 129479.5 10.7 129468.8 0% 10.2