Data Domain: Temizlenebilir Boyut Bir Tahmindir

Summary: Genellikle bir Data Domain sisteminde sunulan "Temizlenebilir GiB" değeri konusunda kafa karışıklığı ve temizleme çalıştırıldıktan sonra kurtarılacak alan miktarı hakkında yanlış beklentiler söz konusudur ...

This article applies to This article does not apply to This article is not tied to any specific product. Not all product versions are identified in this article.

Instructions

Genellikle bir Data Domain sisteminde sunulan "Temizlenebilir GiB" değeri konusunda kafa karışıklığı ve temizleme çalıştırıldıktan sonra kurtarılacak alan miktarı hakkında yanlış beklentiler vardır.

Verilen "Cleanable GiB" sayısı yalnızca bir tahmindir ve Data Domain Dosya Sistemi geliştirilirken yapılan teknolojik seçimler nedeniyle temizleme çalıştırılarak ne kadar alan geri kazanılacağı konusunda kesin bir değer elde etmek mümkün değildir.


Aşağıda, temizlenebilir alan tahminlerinin neden geri kazanılan gerçek alandan önemli ölçüde farklı olabileceğine dair kısa bir açıklama yer almaktadır. Yine de burada hesaba katılmayan başka faktörler de vardır, bu da tahmini ve temiz çalışırken gerçekten serbest bırakılan disk alanı miktarını önemli ölçüde farklı hale getirebilir
 

Data Domain sistemi tarafından veri alındığında, sıkıştırma sonrası değer hesaplanır ve her dosya için statik veri olarak depolanır. Cleanable" değeri, DD temizliğinin son çalıştırılmasından bu yana silinen tüm dosyalar için sıkıştırma sonrası değerin toplamıdır.
 

Silinen dosyaların dosya segmentleri, silinmemiş diğer dosyalardaki tekilleştirmede kullanıldıysa Cleanable değeri hatalı hale gelir. Mevcut bir benzersiz segmente referans veren tek bir dosya olduğu sürece, DD temizleme işlemi bu segmentlerin geri alındığını dikkate almaz. Bu nedenle, bir dosyanın son sıkıştırması, tüm benzersiz bölümleri atılmak üzereymiş gibi "Temizlenebilir GiB" sayacına eklenmiş olsa bile, bazıları (veya çoğu) diğer dosyalar tarafından yeniden kullanıldığı için eklenmeyebilir.
 

Bu etkiyi gösteren daha ayrıntılı bir örnek aşağıdadır:

Bir Data Domain sistemine tek tek eklenmiş 5 dosyanız olduğunu ve daha önce üzerinde başka hiçbir veri bulunmadığını varsayalım.

İlk 100 GB'lık dosyalar tüm benzersiz verileri içerdiğinden, sıkıştırma oranı 1x'tir (ilk dosyanın dosyanın kendisinde herhangi bir fazlalık olmadığı varsayılarak). 2. - 5. dosyalar, 1. dosyanın verilerine ve eklendikçe eski dosyaların her birine karşı veri tekilleştirme yapabildi ve her biri, tekilleştirilecek dosyaların artması nedeniyle artan tekilleştirme kazandı.

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
----------------   ---------   ---------   ---------   ----   --------------


Örnek 1. /backup konumundan ilk 3 dosyayı sildikten sonraki durum:
 

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

 

Bundan sonra Temizleme'yi çalıştırırsanız, temizlenebilir tam 175 yerine 125'i geri alabilirsiniz. Bunun nedeni, son 2 dosyanın segmentleri 1-3 dosyalarıyla paylaşmasıdır.  Bu segmentler 3-5 numaralı dosyalar tarafından kullanılmaya devam ettiğinden temizleme işlemi diğer 50 GB alanı kurtarmaz.
 

Örnek 2: Örnek 1'dekiyle aynı başlangıç noktasını kullanarak, 1. dosyanın silindiğini, ardından /backup klasörünün tamamında (yani 5 dosyanın tümü) hızlı kopyalama yapıldığını ve ardından 2-4 dosyalarının silindiğini varsayalım. 

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

 

Sıkıştırma öncesi için "Boyut GiB" rakamı (500-100)=400*2=800'den gelir, 5 orijinal dosya için 500 verir, dosya 1'i silmek için 100 çıkarmak 400 GiB verir.  Ardından, kalan 4 dosyanın tümündeki hızlı kopyalama nedeniyle 400 GiB 2 ile çarpılır.

Bir dosya kopyası, orijinal verilere meta veri işaretçilerinden oluşan yalnızca küçük bir miktar alan eklediğinden, kullanılan sıkıştırma sonrası alanın hala aynı olduğunu unutmayın. Dosya 1'in silinmesine rağmen alan kullanımı değişmedi çünkü "filesys clean start" çalıştırılmadı (Temizlemeyi başlatmak için). 
 

Temizlikten sonra göreceğiz:
 

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

 

200 GB'ın temizlenebilir olarak gösterilmesine rağmen, yalnızca 25 GB'ın gerçekten temizlendiğini unutmayın. Dosya 1'den 4'e kadar olan "sıkıştırma sonrası" dosya boyutu 200 GB'a kadar eklendiğinden "Temizlenebilir GiB" 200 olarak gösterildi.  Yalnızca 100 GB olan "Dosya 1" kaldırıldı, ancak bunun 75 GB'ı diğer 4 dosya tarafından hala kullanılıyordu (tekilleştirme nedeniyle).  

"Dosya 2" ile "Dosya 4" arasındaki dosyalar da silindiği için bu garip görünebilir, ancak sistem "Dosya 2" ile "Dosya 4" ü kaldırılmış olarak gösterse de, bu dosyalar için gerçek veri segmentlerinin kaldırılamadığını unutmayın.   Ancak tüm hızlı kopya sürümleri de kaldırıldıktan sonra, alan temizlenerek tamamen kurtarılabilir.

 

Temizlenebilir GiB yalnızca bir "tahmin" olduğundan ve doğru olmayabilir , hatta bazen büyük veya Data Domain'in fiziksel kapasitesiyle aynı boyutu yansıtabilir.

Bu durum, Temizlenebilir GiB'nin yakınlarda veya aynı değeri "/data: post-comp" olarak göstermesi nedeniyle DDFS Alanı kullanımı %100'e yaklaşıyorsa zamanlanan DDFS Temizleme işleminin manuel olarak mı yoksa manuel olarak mı çalıştırılmasına izin verileceği konusunda karışıklığa neden olabilir.

Clean'in çalışırken geri kazanacağı disk alanı miktarını tahmin etmede daha iyi ve daha güvenilir bir yönteme sahip olmak için DDOS 7.7.x'ten başlayarak Aktif katmandaki bir sonraki GC'nin geri kazanabileceği gerçek "Toplam Temizlenebilir Alanı" CLI'dan belirlemek artık mümkündür. Bu, CLI'nın bir özetidir:
 

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


İşlem, normal bir GC ile aynı şeyi yapar, 1'den 4'e kadar olan aşamalardan geçer, ancak ölü disk alanını geri kazanmak için kapsayıcıları etkili bir şekilde kopyalayacak olan 5. aşamayı (kopyalama) atlar. Bu nedenle, normal bir GC'nin bir değer döndürmesi 1'den 4'e kadar olan temiz aşamaları tamamlaması kadar uzun sürecektir, bu nedenle bu, güncellenmiş bir tahmine sahip olmak için düzenli olarak çalıştırılacak bir şey değil, yalnızca gerektiğinde çalıştırılacak bir şeydir. Başka bir deyişle, "filesys cleanable-space calculate", GC'yi Alan geri kazandığı kısmı atlayarak Aktif katmanda çalıştırır.

Süreç şu şekilde izlenebilir:
 

# 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

 

Tamamlandığında, temizlenebilir ölçüm sonucuna erişilebilir:

# 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.

 

Yukarıdaki örnek testte DD GC şimdi çalıştırılırsa 94649698202 bayt boş alan oluşması gerekir. Bu 88,1 GiB iken, hesaplama sırasında kullanılan laboratuvar DD'sinde "df" tarafından bildirilen tahmin 41,9 GiB idi. Elbette, FS'de değişiklikler yapıldıkça (yeni yedeklemeler, daha fazla silme, anlık görüntülerin oluşturulması ve süresinin dolması vb.) hesaplama devam edecektir.

Gerekirse, yukarıdaki işlemi durdurmak için aşağıdaki komut kullanılabilir:

# 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.

 

Bu CLI'nin yalnızca DD Aktif katmanı için geçerli olduğunu unutmayın. Yukarıda açıklanan belirsizliklere tabi olarak kendi tahmini olan bir DD bulut birimi için temizlenebilir değeri hesaplamak için eşdeğer bir süreç yoktur.

 

Affected Products

Data Domain

Products

Data Domain
Article Properties
Article Number: 000005806
Article Type: How To
Last Modified: 22 Oct 2025
Version:  6
Find answers to your questions from other Dell users
Support Services
Check if your device is covered by Support Services.