Data Domain Yazılımı : filesys show space (df)" tarafından bildirilen kullanım ile sfs_dump toplamları arasındaki tutarsızlık

"sfs_dump" (veya filesys show compression) işleminin amacı, alma sırasında bir dosya için elde edilen sıkıştırmanın algılanmasına yardımcı olmaktır. Tüketilen toplam alanı yansıtması amaçlanmamıştır.

sfs_dump" ile bildirilen tüm dosyaların sıkıştırma sonrası boyutunun toplamı, yalnızca dosya sisteminde hiçbir silme işlemi gerçekleştirilmemişse toplam alan kullanımıyla eşleşir. Üretim DDR'sinde durum hiçbir zaman böyle değildir, bu nedenle mevcut alan kullanımını hesaba katmak için "sfs_dump" kullanmak bir yanılgıdır. Bunu aşağıda bir örnekle açıklayacağız.
 
 
RESİM:
 
Bu, üç adımlı basit bir örnekle kolayca görülebilir:
 

1.  10G olan bir dosyayı (dosya1) yedekliyorum. Diyelim ki bu yepyeni bir kutu ve kopyalanacak bir şey yok. Sıkıştırma sonrası boyut da bu nedenle 10G civarındadır.

# sfs_dump /data/col1/test/ /data/col1/test/file1: mtime: 1503023531690895000 dosya kimliği: 18 boyut: 10736790004 tipi: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (%0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (%102) modu: 02000100644

 
Yukarıda görüldüğü gibi, sıkıştırma sonrası boyut 10G'dir.


         II.  Ardından, başka bir 10G dosyasını (dosya2) yedekliyorum.  Bu, dosya1 ile çok benzer veya aynı.   

# sfs_dump /data/col1/test /data/col1/test/file1: mtime: 1503023531690895000 dosya kimliği: 18 boyut: 10736790004 tipi: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 0 (%0%) pre_lc_size: 10772785048 post_lc_size: 10942680452 (%102) modu: 02000100644 /data/col1/test/file2: mtime: 1503023531690895000 dosya kimliği: 19 boyut: 10736790004 tipi: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (%100) pre_lc_size: 0 post_lc_size: 0 (%0) modu: 02000100644

 
Yukarıda görüldüğü gibi, dosya2, dosya1 ile tamamen tekilleştirildiği için ek alan kullanmadı.
 

          III.   Şimdi File1'i siliyorum ve mtree üzerinde tekrar "sfs_dump" çalıştırıyorum.  

# sfs_dump /data/col1/test /data/col1/test/file2: mtime: 1503023531690895000 dosya kimliği: 19 boyut: 10736790004 tipi: 9 seg_bytes: 10772785048 seg_count: 1282587 redun_seg_count: 1282587 (%100) pre_lc_size: 0 post_lc_size: 0 (%0) modu: 02000100644

 
 
Yukarıdakilere bağlı olarak müşteri, dosya sisteminde alan tüketilmemesini bekleyebilir.  MTree'deki tek dosya sıkıştırıldıktan sonra 0 bayt yer kaplar (sfs_dump tarafından bildirilen tüm dosyaların toplamı 0 bayttır).  Ama bu bir yanılgıdır. Sistemdeki alan kullanımı aslında 10G'dir ve df ile doğru bir şekilde yansıtılır. 
 
Bunun nedeni, Dosya2'nin orijinal olarak Dosya1 tarafından yazılmış tüm segmentlere başvurmasıdır.  Dosya1'in silinmesi hiçbir şeyi serbest bırakmadı. sfs_dump", silindiği için orijinal Dosya1'i göstermez.

# df Active Tier: Kaynak Boyutu GiB Kullanılmış GiB Kullanılabilir GiB Kullanım Yüzdesi Temizlenebilir GiB* ---------------- -------- -------- --------- ---- -------------- /data: pre-comp - 10.0 - - - /Data: Post-Comp 129479.5 10.7 129468.8 0% 10.2