Bir Data Domain'de kullanılan sıkıştırma teknikleri, müşteri verileri için gereken fiziksel alanı azaltmak için en gelişmiş teknikleri kullanır. Ayrıca, sıkıştırma düzeylerine ilişkin teknolojiler ve ölçümler son derece karmaşık konulardır. Bu belgede, bir Data Domain sisteminde kullanılan sıkıştırma türlerini, terminolojiyi ve sıkıştırmanın diğer yönlerini daha iyi açıklamak için bazı terminolojiler, ödünleşimler ve önlemler ele alınmaktadır.
ŞUNLAR IÇIN GEÇERLIDIR:
Tüm Data Domain Modelleri
Son güncelleme tarihi: Ocak 2024
Sıkıştırma, bir veri kümesini daha az fiziksel alan kullanarak depolamayı amaçlayan bir veri azaltma teknolojisidir. Data Domain sistemlerinde (DDOS), kullanıcı verilerini sıkıştırmak için tekilleştirme ve yerel sıkıştırma yaparız. Fazlalık veri segmentlerini tespit etmek ve yalnızca benzersiz veri segmentlerini depolamak için tekilleştirme veya "dedupe" kullanılır. Yerel sıkıştırma, benzersiz veri segmentlerini aşağıdakiler gibi belirli sıkıştırma algoritmalarıyla daha da sıkıştırır: lz, gzfast, gz, benzeri. DDOS'ta genel kullanıcı veri sıkıştırması, tekilleştirme ve yerel sıkıştırmanın ortak çabasıdır. DDOS, veri sıkıştırma işleminin etkililiğini ölçmek için "compression ratio" (sıkıştırma oranı) değerini kullanır. Genel olarak, toplam kullanıcı veri boyutunun, sıkıştırılmış verilerin toplam boyutuna veya kullanılan fiziksel alan boyutuna oranıdır.
Data Domain dosya sistemi, "günlük yapılı" bir tekilleştirme dosya sistemidir. Günlük yapılandırmalı dosya sistemleri yalnızca sisteme veri ekleyebilir; silme işlemi tek başına fiziksel alan açamaz. Bu tür dosya sistemleri, artık gerekli olmayan alanı geri kazanmak için çöp toplama işlemini kullanır. Günlük yapılı dosya sisteminin özellikleri ve tekilleştirilmiş teknoloji bir araya geldiğinde, DDOS'ta sıkıştırmanın tüm yönlerini net bir şekilde anlamayı zorlaştırır.
Sıkıştırma için ölçebileceğimiz birçok husus vardır. Bu belgede, DDOS sıkıştırmasının anlaşılmasına yardımcı olmak için ayrıntıları adım adım ele alacağız. İlk başta, bize bir Data Domain sisteminde elde edilen gerçekçi sıkıştırmayı, kullanıcı verisi miktarını, tüketilen fiziksel alan miktarını ve bunların oranını söyleyen genel sistem sıkıştırma etkisini açıklıyoruz. Bu oran, bu belgede "sistem etkin sıkıştırma oranı" olarak adlandırılmaktadır. DDOS, tekilleştirmeyi satır içi olarak gerçekleştirir ve orijinal kullanıcı veri segmentlerinin istatistiklerini, tekilleştirme sonrası benzersiz veri segmentlerini ve benzersiz veri segmentleri üzerindeki yerel sıkıştırma etkisini izler. Bu satır içi sıkıştırma istatistikleri, satır içi sıkıştırma etkisini ölçmek için kullanılır. Satır içi sıkıştırma istatistikleri her yazma için ölçülebilir. Ayrıca DDOS, istatistikleri farklı seviyelerde takip eder; dosyalar, MTree'ler ve tüm sistem.
Bu belgenin içeriği, bu belgenin yayınlanmasına kadar DDOS 7.13 e kadar tüm DDOS sürümlerine uygulanabilir. İçeriğinin tamamının gelecek sürümler için geçerli olacağına dair bir garanti yoktur. 5.0'dan önceki sürümlerde tüm sistemde yalnızca bir mtree bulunur ve mtree terimi açıkça belirtilmez.
Sistem genelinde genel sıkıştırma etkisi, kullanıcı veri boyutunun kullanılan fiziksel alan boyutuna oranı olan sistem etkin sıkıştırma oranı ile ölçülür. filesys show compression (FSC) CLI komutuyla bildirilir (ilgili bilgiler kullanıcı arayüzünde de mevcuttur). FSC'nin örnek bir çıktısı aşağıda gösterilmiştir:
# 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.
Sistem etkin sıkıştırma oranı, CLI çıktısında sonuç bölümünün 1. satırında bildirilir. Satır yukarıda vurgulanmıştır. Toplam kullanıcı verisi boyutu "Ön Sıkıştırma" olarak etiketlenir. Tüketilen toplam fiziksel alan (hem verilere hem de meta verilere göre) "Post-Comp" olarak etiketlenir.
"Pre-Comp" numarası ve "Post-Comp" numarasının her ikisi de çalışma zamanında okunur. FSC, sistemin tamamını örtük olarak senkronize eder ve ardından bu iki sayıyı sorgular. Bu iki sayı, "filesys show space" komutuyla aynı şekilde ölçülür.
Sistem etkin sıkıştırma oranı = Sıkıştırma Öncesi/Sıkıştırma Sonrası
FSC çıktısının geri kalanı, satır içi sıkıştırma istatistiklerini açıklar ve bunları daha sonra tartışacağız.
Sistemin etkin sıkıştırma oranını etkileyebilecek bazı işlemler vardır:
Hızlı kopyalama
Hızlı kopyalama, etkin ad alanındaki bir dosyadan (anlık görüntü değil) yapıldığında, hedef dosya için fazladan fiziksel alan gerekmediğinden mükemmel bir tekilleştirmedir. Fastcopy işleminin etkisi, ek fiziksel alan kullanmadan kullanıcı veri boyutunu artırabilmemizdir. Bu, sistem etkin sıkıştırma oranını artırır. Çok sayıda hızlı kopyalama yapıldığında, sistem etkin sıkıştırma oranı yapay olarak yüksek olabilir.
Sanal sentetikler
Sanal sentetik yedeklemeler, yüksek bir sistem etkin sıkıştırma oranı gösterme eğilimindedir. Bunun nedeni, sanal sentetiklerin mantıksal tam yedeklemeler yapması, ancak yalnızca değişen veya yeni verileri Data Domain sistemlerine aktarmasıdır. Sanal sentetiklerin sistem etkili sıkıştırma oranına etkisi, hızlı kopyalamanın etkisine biraz benzer.
Geçersiz kılar
Üzerine yazmalar daha fazla fiziksel alan tüketir ancak veri kümesinin mantıksal boyutunu artırmaz, dolayısıyla üzerine yazmalar sistemin etkin sıkıştırma oranını düşürür.
Seyrek dosyaları depolama
Seyrek dosyalar, mantıksal boyuta dahil edilen ancak sıkıştırma nedeniyle fiziksel alan kullanmayan büyük "delikler" içerir. Sonuç olarak bu dosyalar, sistemde geçerli sıkıştırma oranını yüksek hale getirebilir.
Küçük dosyaları depolama
DDOS, belirli dahili meta veriler için her dosyaya yaklaşık 1 KB ek yük ekler. Bir sistem çok sayıda küçük dosya depoladığında (boyutları 1 KB'den küçük veya tek basamaklı kilobayt cinsinden), meta veri yükü etkin sıkıştırma oranını aşağı çeker.
Önceden sıkıştırılmış veya önceden şifrelenmiş dosyaları depolama
Sıkıştırma ve şifreleme, veri değişikliği düzeyini artırabilir ve tekilleştirme olasılığını azaltabilir. Bu tür dosyalar genellikle iyi bir şekilde tekilleştirilemez ve sistemin etkin sıkıştırma oranını düşürür.
Silme
Silme işlemleri sistemin mantıksal boyutunu düşürse de sistem, çöp toplama işlemi çalıştırılana kadar söz konusu kullanılmayan alanı geri kazanmaz. Silinen birçok dosya, Çöp Toplama (GC) çalıştırılana kadar sıkıştırma oranını düşürür.
Çöp Toplama (GC) veya Temizleme
GC, artık hiçbir dosya tarafından görülmeyen veri segmentleri tarafından tüketilen alanı geri alır. Yakın zamanda çok sayıda dosya silindiyse GC, fiziksel alan kullanımı ayak izini azaltarak sistem sıkıştırma oranını artırabilir.
Agresif bir şekilde anlık görüntüler alma
Bir Mtree'nin anlık görüntüsünü aldığımızda veri kümesinin mantıksal boyutunu değiştirmeyiz. Ancak, anlık görüntü tarafından yakalanan tüm dosyalar anlık görüntü alındıktan sonra silinse bile anlık görüntü tarafından başvurulan tüm veri segmentleri kilitlenmelidir. GC, anlık görüntüler için hala ihtiyaç duyulan alanı geri kazanamaz; Bu nedenle, çok sayıda anlık görüntüye sahip olmak sistem etkin sıkıştırma oranının düşük görünmesine neden olabilir. Ancak anlık görüntüler, kilitlenme durumunda kurtarma için kullanışlıdır. Gerektiğinde anlık görüntüler almanız veya uygun anlık görüntü zamanlamaları ayarlamanız mutlaka önerilir.
DDOS, veri sisteme yazılırken tekilleştirmeyi satır içi olarak gerçekleştirir. Her yazma için satır içi tekilleştirme ve yerel sıkıştırmanın etkilerini izler ve istatistikleri dosya düzeyinde toplar. Dosya başına satır içi sıkıştırma istatistikleri, mtree düzeyinde ve sistem düzeyinde daha fazla toplanır. Sıkıştırma, satır içi istatistiklerdeki üç sayıya göre ölçülür:
Yukarıdaki üç sayıyı temel alarak, DDOS iki tane daha ince tanecikli sıkıştırma oranı tanımlar:
Toplanan satır içi sıkıştırma istatistikleri, DDOS'deki dosya meta verilerinin bir parçasıdır ve dosya inode'dunda depolanır. DDOS, her üç düzeyde de satır içi sıkıştırmaları kontrol etmek için araçlar sağlar; dosya, MTree ve sistem genelinde. Bunları aşağıdaki bölümlerde detaylandırıyoruz.
3.1 Dosya Sıkıştırma
Dosya sıkıştırması, dosya inode'unda depolanan birikmiş sıkıştırma istatistiklerini bildiren "filesys show compression <path>" CLI komutuyla kontrol edilebilir. Bir dizin belirtildiğinde, bu dizin altındaki tüm dosyaların satır içi sıkıştırma istatistikleri toplanır ve raporlanır. CLI çıkışında raw_bytes, "Original Bytes" olarak etiketlenir; pre_lc_size, "Küresel Olarak Sıkıştırılmış" olarak etiketlenir; post_lc_bytes "Yerel Olarak Sıkıştırılmış" olarak işaretlenir; diğer genel giderler "Meta veriler" olarak raporlanır. İki örnek, gerçek bir DD:
Örnek 1'den alınmıştır: Bir dosyanın satır içi sıkıştırma istatistikleri
# 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
Örnek 2: Tüm alt dizinler dahil olmak üzere bir dizin altındaki tüm dosyaların satır içi sıkıştırma istatistikleri
# 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
Sistem, yukarıdaki CLI çıktısındaki genel satır içi sıkıştırma oranını "bayt/storage_used" olarak bildirir. Ancak yukarıdaki bilgiler çeşitli nedenlerle yanıltıcı olabileceğinden, söz konusu bilgiler dikkatli bir şekilde yorumlanmalıdır. Bunun bir nedeni, pre_lc_size ve post_lc_size değerlerinin veri işlemleri yürütüldüğü zaman kayıt altına alınmasıdır. Bu segmentleri ilk ekleyen dosya silindiğinde, kalan dosyadaki benzersiz veri segmentlerinin sayısı artırılmalıdır.
Örneğin, sample.file dosyasının bir Data Domain'e yedeklendiğini ve ilk yedeklemede dosyanın sıkıştırma bilgisinin pre_lc_size=10GiB, post_lc_size=5Gib olduğunu varsayalım.
Ardından, bu dosyanın verilerinin benzersiz olduğunu ve başka herhangi bir dosyayla veri paylaşmadığını varsayalım. Dosyanın ikinci yedeklemesinde, dosyanın ideal tekilleştirmeye sahip olduğunu varsayın; öyle ki, dosyanın tüm segmentleri sistemde zaten mevcut olduğundan hem pre_lc_size hem de post_lc_size sıfır olmalıdır. İlk yedek silindiğinde, dosyanın ikinci yedeği 5 GiB veri segmentine başvuran tek dosya olur. Bu durumda, ideal olarak, ikinci yedekteki dosyanın pre_lc_size ve post_lc_size her ikisi de sıfırdan sırasıyla 10 GiB ve 5 GiB olacak şekilde güncelleştirilmelidir. Ancak bunun hangi dosyalar için yapılması gerektiğini algılamanın bir yolu yoktur, bu nedenle mevcut dosyaların satır içi sıkıştırma istatistikleri değişmeden kalır.
Yukarıdaki sayıları etkileyen bir diğer faktör de kümülatif istatistiklerdir. Bir dosya çok fazla üzerine yazma işlemi aldığında, kümülatif istatistiklerin canlı verileri tanıtan yazmaları ne ölçüde yansıttığını izlemek imkansızdır. Bu nedenle, uzun bir süre boyunca, satır içi sıkıştırma istatistikleri, yalnızca belirli bir dosyanın sıkıştırmasını kabaca tahmin etmek için bir buluşsal yöntem olarak ele alınabilir.
Vurgulanmaya değer bir başka gerçek de, bir dosyanın satır içi sıkıştırmasının rastgele bir zaman aralığı için ölçülememesidir. Dosya satır içi sıkıştırma istatistikleri kümülatif bir sonuçtur ve dosyanın şimdiye kadar aldığı tüm yazma işlemlerini kapsar. Bir dosyaya çok sayıda üzerine yazma işlemi yapılırsa raw_bytes, dosyanın mantıksal boyutundan çok daha büyük olabilir. Seyrek dosyalar için dosya boyutları "Orijinal Bayt"tan daha büyük olabilir.
3.2 MTree Sıkıştırma
Belirli bir mtree'nin sıkıştırmasını "mtree show compression" (MSC) CLI komutu. Satır içi sıkıştırma istatistiklerinin mutlak değerleri, MTree'nin kullanım ömrü boyunca kümülatiftir. Bir MTree'nin ömrünün uzun yıllar sürebileceği göz önüne alındığında, bu değerler zamanla daha az bilgilendirici hale gelir. Bu sorunu gidermek için satır içi sıkıştırma istatistiklerindeki değişiklik miktarını (deltas) kullanırız ve sıkıştırmayı yalnızca belirli zaman aralıkları için raporlarız. Temel yaklaşım, MTree satır içi sıkıştırma istatistiklerini düzenli aralıklarla bir günlüğe dökmemizdir. Bir istemci MSC komutuyla MTree sıkıştırmasını sorguladığında, sıkıştırma raporlaması için sayıların deltalarını hesaplamak üzere günlüğü kullanırız. Varsayılan olarak, MSC son 7 gün ve son 24 saat için sıkıştırma bildirir, ancak herhangi bir ilgili zaman aralığı belirtilebilir.
Bunu göstermek için MTree A için aşağıdaki günlüğü varsayalım:
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
O zaman bu saat için MTree A'nın sıkıştırması:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Yukarıdaki sıkıştırma oranı hesaplaması, veri kümesi boyutuyla hiçbir şey yapmaz. Örneğin, yukarıdaki mtree yalnızca 500 GB mantıksal veriye sahip olabilir.
MSC, "filesys show compression" komutunda olduğu gibi "daily" ve "daily-detailed" seçeneklerini destekler. daily" belirtildiğinde, komut günlük sıkıştırmayı takvim biçiminde bildirir. Günlük sıkıştırma oranının hesaplanması için raw_bytes ve post_lc_size değerlerinin günlük deltaları kullanılır. "Daily-detailed" belirtildiğinde, komut her gün için üç deltayı da (sırasıyla raw_bytes, pre_lc_size ve post_lc_size'nin) gösterir; Ayrıca toplam sıkıştırma faktörünün yanı sıra g_comp ve l_comp da hesaplar.
Bu sistemlerden alınan örnek çıktı Ek'te yer almaktadır.
3.3 Sistem Sıkıştırma
MTree'lerde sıkıştırmanın nasıl raporlandığını anladıktan sonra, konsepti tüm sisteme genişletmek kolaydır. Sistem genelinde sıkıştırma, satır içi istatistiklerin toplanması ve raporlanması, MTree'lerdekiyle tamamen aynıdır. Tek fark, biri belirli bir MTree'de, diğeri ise tüm sistemin üzerinde olduğu için kapsamdır. Sonuçlar "filesys show compression" komutu kullanılarak kontrol edilebilir. Bunun bir örneği Bölüm 2'de bulunabilir. "Son 7 gün" ve "son 24 saat" sistem sıkıştırması, FSC çıktısındaki sonuç bölümünün son iki satırında rapor edilir.
Bulut katmanı uygulanmış DD'lerde depolama, iki bağımsız tekilleştirme etki alanı olan aktif katmana ve bulut katmanına ayrılır. Kullanıcılar verileri yalnızca aktif katmana ekleyebilir. Daha sonra, verileri aktif katmandan bulut katmanına geçirmek için DDOS veri taşıma işlevleri kullanılabilir. Böylece alan ve sıkıştırma ölçümü ve raporlaması her katmanda bağımsız olarak ele alınır. Ancak dosya düzeyinde, katmana göre ayrım yapmıyoruz ve satır içi sıkıştırma istatistiklerini raporluyoruz; Bölüm 3.1'de anlattıklarımızla tamamen aynıdırlar.
Vurgulanması gereken son konu, birçok Data Domain belgesinde "genel sıkıştırma" olarak adlandırılan tekilleştirmenin bazı özellikleridir. "Sıkıştırma" kelimesini içermesine rağmen, DDOS tarafından "yerel sıkıştırma" adı altında da sağlanan geleneksel sıkıştırma kavramından tamamen farklıdır.
Yerel sıkıştırma, belirli bir algoritma kullanarak bir veri parçasının boyutunu azaltır (bazı veri türleri sıkıştırılamaz ve üzerlerine sıkıştırma algoritmaları uygulamak veri boyutunu biraz artırabilir). Genellikle, bir algoritmaya karar verildikten sonra, verilerin kendisi sıkıştırma oranının tek faktörüdür.
Bununla birlikte, tekilleştirme farklıdır - yerel bir kavram değil, "küresel" dir. Gelen bir veri segmenti, bulut olmayan Data Domain sistemlerindeki tüm verileri içeren, tekilleştirilmiş bir etki alanındaki mevcut tüm veri segmentleriyle karşılaştırılarak tekilleştirilir. Tekilleştirme prosedüründe veri segmentinin kendisi önemli değildir.
Uygulamada, bir veri kümesinin ilk yedeklemesinde yüksek tekilleştirme oranını nadiren görürüz. İlk yedeklemelerde veri azaltımı çoğunlukla yerel sıkıştırma ile sağlanır. Sonraki yedeklemeler Data Domain'e ulaştığında tekilleştirme gücünü gösterir ve sıkıştırma için baskın faktör haline gelir. Tekilleştirmenin etkinliği, bir veri kümesinin değişiklik hızının yedeklemeden yedeklemeye düşük olmasına dayanır. Bu nedenle, yüksek değişim oranlarına sahip veri kümeleri iyi bir şekilde tekilleştirilemez. Yedekleme uygulaması, kendi meta veri öbeklerini (Data Domain tarafından işaretleyiciler olarak adlandırılır) yedekleme görüntülerine yüksek frekansta eklediğinde de iyi bir tekilleştirme oranı elde edemeyebilir. İşaretleyici işleme tekniklerimiz her zaman olmasa da bazen yardımcı olabilir.
Bu gözlemler göz önüne alındığında, ne bekleyebiliriz?
Sıkıştırmayı ölçmek, tekilleştirilmiş dosya sistemlerinde zordur, ancak günlük yapılı tekilleştirilmiş dosya sistemlerinde daha da zordur. Tekilleştirmenin nasıl çalıştığını ve sıkıştırma istatistiklerinin nasıl izlendiğini anlamalıyız. Sıkıştırma oranları, belirli bir sistemin davranışını anlamak için yararlı bilgilerdir. Sistem etkin sıkıştırma oranı en önemli, güvenilir ve bilgilendirici ölçüdür. Satır içi sıkıştırma istatistikleri de yardımcı olabilir, ancak bazı durumlarda buluşsal yöntemlerden başka bir şey olmayabilir.
Ekler: Örnek çıktı: "mtree show compression" komutu
: 254792,4 GiB veri tutan bir MTree olduğunu varsayalım. Son 7 günde 4379,3 GiB ve son 24 saatte 78,4 GiB yeni veri aldı (diğer zaman aralıkları belirtilebilir). "Daily" (günlük) seçeneği son 33 güne ait satır içi sıkıştırma istatistiklerini raporlar. "Günlük ayrıntılı" seçeneği sağlandığında, toplam sıkıştırma oranları, global ve yerel sıkıştırma oranlarına ayrılarak daha da ayrıntılı hale getirilir.
Mtree List çıktısı:
# 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
# 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)
------------- -------- --------- ----------- ---------- -------------
"Günlük" seçeneğiyle:
# 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
"Günlük ayrıntılı" seçeneği ile:
# 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