Data Domainiin liittyvissä pakkaustekniikoissa käytetään uusimpia tekniikoita asiakastietojen vaatiman fyysisen tilan vähentämiseksi. Pakkaustasojen tekniikat ja mittaukset ovat näin ollen monimutkaisia aiheita. Tässä asiakirjassa käsitellään joitakin termejä, kompromisseja ja toimenpiteitä, jotta voidaan selittää paremmin käytetyt pakkaustyypit, terminologia ja muut Data Domain -järjestelmän pakkaamiseen liittyvät näkökohdat.
KOSKEE SEURAAVIA:
Kaikki Data Domain -mallit
Viimeksi päivitetty: Tammikuu 2024
Pakkaus on tietojen vähentämistekniikka, jonka tarkoituksena on tallentaa tietojoukko käyttämällä vähemmän fyysistä tilaa. Data Domain Systems (DDOS) -järjestelmissä tehdään deduplikointia ja paikallista pakkausta käyttäjätietojen pakkaamiseksi. Päällekkäisten tietosegmenttien tunnistamiseen ja vain yksilöivien tietosegmenttien tallentamiseen käytetään kaksoiskappaleiden poistamista eli dedupe-menetelmää. Paikallinen pakkaus pakkaa yksilöllisiä datasegmenttejä edelleen tietyillä pakkausalgoritmeilla, kuten lz, gzfast, gz, niin edelleen. DDOS:n käyttäjätietojen yleinen pakkaus on tieto-optimoinnin ja paikallisen pakkauksen yhteinen ponnistus. DDOS mittaa tietojen pakkaamistehokkuutta pakkaussuhteella. Yleensä se on käyttäjätietojen kokonaiskoon suhde pakatun datan kokonaiskokoon tai käytetyn fyysisen tilan kokoon.
Data Domain -tiedostojärjestelmä on lokirakenteinen deduplikointitiedostojärjestelmä. Lokirakenteinen tiedostojärjestelmä ainoastaan liittää järjestelmään tietoja, eikä poistaminen itsessään vapauta fyysistä tilaa. Kyseiset tiedostojärjestelmät vapauttavat tilaa, jota ei enää tarvita, käyttämällä muistin tiivistämistä. Lokirakenteisen tiedostojärjestelmän ja deduplikoidun tekniikan ominaisuudet yhdessä tekevät DDOS:n pakkauksen kaikkien näkökohtien selkeästä ymmärtämisestä hankalaa.
Pakkausta varten voimme mitata monia näkökohtia. Tässä asiakirjassa käsitellään yksityiskohtia vaihe vaiheelta DDOS-pakkauksen ymmärtämiseksi. Aluksi selitämme järjestelmän yleisen pakkausvaikutuksen, joka kertoo meille Data Domain -järjestelmässä saavutetun realistisen pakkauksen, käyttäjätietojen määrän, kulutetun fyysisen tilan määrän ja niiden suhteen. Tätä suhdetta kutsutaan tässä asiakirjassa "järjestelmän teholliseksi pakkaussuhteeksi". DDOS suorittaa deduplikoinnin upotettuna ja seuraa alkuperäisten käyttäjätietosegmenttien tilastoja, dedupin jälkeisiä yksilöllisiä datasegmenttejä ja paikallista pakkausvaikutusta yksilöllisiin datasegmentteihin. Kyseisiä inline-pakkaustilastoja käytetään inline-pakkaustehokkuuden mittaamiseen. Inline-pakkaustilastot voidaan mitata jokaiselle kirjoitukselle. DDOS seuraa myös tilastoja eri tasoilla; tiedostot, MTreet ja koko järjestelmä.
Tämän asiakirjan sisältöä voi soveltaa kaikkiin DDOS-julkaisuihin tämän asiakirjan julkaisemiseen asti, DDOS 7.13 -versioon asti. Vastaisuudessa julkaistavien versioiden koko sisällön paikkansapitävyyttä ei voida taata. 5.0-versiota edeltävissä versioissa koko järjestelmässä on vain yksi mtree, eikä termiä mtree ole nimenomaisesti mainittu.
Koko järjestelmän kattavaa kokonaispuristusvaikutusta mitataan järjestelmän tehollisella pakkaussuhteella, joka on käyttäjätietojen koon suhde käytetyn fyysisen tilan kokoon. Siitä ilmoitetaan filesys show compression (FSC) CLI -komennolla (vastaavat tiedot ovat saatavilla myös käyttöliittymässä). FSC:n näytetulos on esitetty alla:
# 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.
Järjestelmän efektiivinen puristussuhde ilmoitetaan komentoriviliittymän tuloksen tulososion rivillä 1. Rivi on korostettu edellä. Käyttäjädatan kokonaiskooksi on merkitty "Pre-Comp". Fyysisen tilan kokonaismäärä (sekä tietojen että metatietojen perusteella) on merkitty "Post-Compiksi".
Pre-Comp-numero ja Post-Comp-numero luetaan suorituksen aikana. FSC synkronoi implisiittisesti koko järjestelmän ja kysyy sitten näitä kahta numeroa. Nämä kaksi lukua mitataan samalla tavalla kuin "filesys show space" -komento.
Järjestelmän efektiivinen puristussuhde = Pre-Comp/Post-Comp
Loput FSC-tuloksesta kuvaavat inline-pakkaustilastoja, ja käsittelemme niitä myöhemmin.
Jotkut toiminnot voivat vaikuttaa järjestelmän tehokkaaseen pakkaussuhteeseen:
Nopea kopiointi
Kun pikakopio tehdään aktiivisessa nimitilassa olevasta tiedostosta (ei tilannevedoksesta), se on täydellinen deduplikointi, koska kohdetiedostolle ei tarvita ylimääräistä fyysistä tilaa. Pikakopion vaikutus on se, että se lisää käyttäjätietojen kokoa käyttämättä lisää fyysistä tilaa. Tämä lisää järjestelmän tehokasta puristussuhdetta. Kun nopeita kopioita tehdään useita, järjestelmän tehokas pakkaussuhde voi nousta keinotekoisen korkeaksi.
Virtuaaliset synteettiset materiaalit
Virtuaaliset synteettiset varmuuskopiot näyttävät yleensä korkean järjestelmän tehokkaan pakkaussuhteen. Tämä johtuu siitä, että virtuaalisynteettiset tiedostot tekevät loogiset täydelliset varmuuskopiot, mutta vain siirretyt tai uudet tiedot siirretään Data Domain -järjestelmiin. Virtuaalisynteettisten materiaalien vaikutus järjestelmän tehokkaaseen pakkaussuhteeseen on jonkin verran kuin fastcopyn vaikutus.
Korvaa
Korvaukset vievät enemmän fyysistä tilaa, mutta eivät kasvata tietojoukon loogista kokoa, joten ne pienentävät järjestelmän tehokasta pakkaussuhdetta.
Harvojen tiedostojen tallentaminen
Hajanaisissa tiedostoissa on suuria reikiä, jotka lasketaan loogiseen kokoon, mutta jotka pakkaamisen ansiosta eivät vie fyysistä tilaa. Siksi ne saavat järjestelmän tehollisen pakkaussuhteen näyttämään korkealta.
Pienten tiedostojen tallentaminen
DDOS lisää lähes 1 kt yleiskustannuksia jokaiseen tiedostoon tiettyjen sisäisten metatietojen osalta. Kun järjestelmä tallentaa huomattavan määrän pieniä tiedostoja (kooltaan alle 1 kt tai yksinumeroisina kilotavuina), metatietojen yleiskustannukset vetävät efektiivistä pakkaussuhdetta alaspäin.
Esipakattujen tai salattujen tiedostojen tallentaminen
Pakkaaminen ja salaus voivat tehostaa tietojen muuttumista ja vähentää deduplikoinnin mahdollisuutta. Tällaisia tiedostoja ei yleensä voida kopioida hyvin ja alentaa järjestelmän tehokasta pakkaussuhdetta.
Poistaa
Poistot pienentävät järjestelmän loogista kokoa, mutta järjestelmä ei saa vastaavaa käyttämätöntä tilaa takaisin ennen kuin muisti tiivistetään. Monet poistetut tiedostot tekevät pakkaussuhteesta alhaisen, kunnes Garbage Collection (GC) suoritetaan.
Roskien keräys (GC) tai siivous
GC vapauttaa tilaa datasegmenteille, joita mikään tiedosto ei enää näe. Jos äskettäin on poistettu suuri määrä tiedostoja, muistin tiivistäminen saattaa parantaa järjestelmän pakkaussuhdetta pienentämällä fyysisen tilan kulutusta.
Tilannekuvien aggressiivinen ottaminen
Kun otamme tilannevedoksen Mtreestä, emme muuta tietojoukon loogista kokoa. Kaikki tilannevedoksessa viitatut tietosegmentit on kuitenkin lukittava, vaikka kaikki tilannevedokseen tallennetut tiedostot poistettaisiin tilannevedoksen ottamisen jälkeen. GC ei voi ottaa takaisin tilaa, jota tilannevedokset vielä tarvitsevat; Siksi järjestelmän tehokas pakkaussuhde saattaa vaikuttaa alhaiselta, jos tilannevedoksia on paljon. Tilannevedokset ovat kuitenkin hyödyllisiä kaatumisen palautustoimintoja. Älä koskaan epäröi ottaa tilannevedoksia tai määrittää tarvittavia tilannevedosajastuksia.
DDOS suorittaa deduplikoinnin inline, kun tiedot kirjoitetaan järjestelmään. Se seuraa sisäisen tieto-optimoinnin ja paikallisen pakkauksen vaikutuksia jokaisen kirjoituksen yhteydessä ja kerää tilastot tiedostotasolla. Tiedostokohtaiset inline-pakkaustilastot koostetaan edelleen mtree- ja järjestelmätasolla. Pakkausta mitataan kolmen numeron perusteella inline-tilastoissa:
Edellä mainittujen kolmen numeron perusteella DDOS määrittää vielä kaksi hienorakeisuuden pakkaussuhdetta:
Kertyneet inline-pakkaustilastot ovat osa DDOS:n tiedostojen metatietoja, ja ne tallennetaan inode-tiedostoon. DDOS tarjoaa työkaluja inline-pakkausten tarkistamiseen kaikilla kolmella tasolla; tiedosto, MTree ja koko järjestelmän laajuisesti. Kerromme niistä yksityiskohtaisesti seuraavissa osissa.
3.1 Tiedostojen pakkaus
Tiedostojen pakkaamisen voi tarkistaa komentoriviliittymän filesys show compression <path>, joka raportoi inodeen tallennetut kertyneet pakkaustilastot. Kun hakemisto on määritetty, kaikkien hakemistossa olevien tiedostojen sisäiset pakkaustilastot lasketaan yhteen ja raportoidaan. CLI-lähdössä raw_bytes on merkitty nimellä "Original Bytes"; pre_lc_size on merkitty "maailmanlaajuisesti pakatuksi"; post_lc_bytes on merkitty "paikallisesti pakatuksi"; muut yleiskustannukset raportoidaan metatietoina. Nämä kaksi esimerkkiä on otettu todellisesta DD:
Esimerkki 1: Tiedoston sisäiset pakkaustilastot
# 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
Esimerkki 2: Kaikkien hakemistossa olevien tiedostojen sisäiset pakkaustilastot, mukaan lukien kaikki alihakemistot
# 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
Järjestelmä ilmoittaa yleisen inline-pakkaussuhteen yllä olevassa komentoriviliittymän tuloksessa muodossa "tavua / storage_used". Edellä esitettyjä tietoja on kuitenkin tulkittava huolellisesti, sillä ne voivat olla monista syistä harhaanjohtavia. Yksi syy on se, että pre_lc_size ja post_lc_size tallennetaan tietojen käsittelyn yhteydessä. Kun kyseiset segmentit alun perin lisännyt tiedosto poistetaan, jäljellä olevan tiedoston yksilöllisten datasegmenttien määrää on lisättävä.
Oletetaan esimerkiksi, että tiedosto sample.file on varmuuskopioitu Data Domainiin, ja ensimmäisessä varmuuskopiossa tiedoston pakkaustiedot ovat pre_lc_size=10GiB, post_lc_size=5Gib.
Oletetaan seuraavaksi, että tämän tiedoston tiedot ovat yksilöllisiä eikä tietoja jaeta minkään muun tiedoston kanssa. Oletetaan edelleen tiedoston toisessa varmuuskopiossa, että tiedosto saa ihanteellisen deduplikoinnin siten, että sekä pre_lc_size että post_lc_size pitäisi olla nolla, koska kaikki tiedoston segmentit olivat jo olemassa järjestelmässä. Kun ensimmäinen varmuuskopio poistetaan, tiedoston toisesta varmuuskopiosta tulee ainoa tiedosto, joka viittaa datasegmenttien 5 gigatavuun. Tässä tapauksessa ihannetapauksessa toisessa varmuuskopiossa olevan tiedoston pre_lc_size ja post_lc_size tulisi päivittää nollasta vastaavasti 10 GiB: iin ja 5 GiB: iin. Ei kuitenkaan ole mitään keinoa havaita, mille tiedostoille se pitäisi tehdä, joten olemassa olevien tiedostojen sisäiset pakkaustilastot jätetään ennalleen.
Toinen tekijä, joka vaikuttaa edellä mainittuihin lukuihin, on kumulatiiviset tilastot. Kun tiedosto saa paljon korvauksia, on mahdotonta seurata, missä määrin kumulatiiviset tilastot vastaavat reaaliaikaisten tietojen käyttöönottoa käyttäviä kirjoituksia. Siten pitkän ajan kuluessa sisäisiä pakkaustilastoja voidaan pitää vain heuristiikkana tietyn tiedoston pakkauksen karkeaksi arvioimiseksi.
Toinen korostamisen arvoinen seikka on, että tiedoston sisäistä pakkausta ei voida mitata mielivaltaisella aikavälillä. Tiedoston sisäiset pakkaustilastot ovat kumulatiivinen tulos ja kattavat kaikki tiedoston koskaan saamat kirjoitukset. Kun tiedosto saa paljon korvauksia, raw_bytes voi olla paljon suurempi kuin tiedoston looginen koko. Harvoissa tiedostoissa tiedostokoot voivat olla suurempia kuin "alkuperäiset tavut".
3.2 MTree-pakkaus
Voimme tarkistaa tietyn mtreen pakkauksen "mtree show compression" (MSC) komentoriviliittymän komento. Inline-pakkaustilastojen absoluuttiset arvot ovat kumulatiivisia MTree:n elinkaaren ajalta. Koska MTree:n käyttöikä voi olla useita vuosia, näistä arvoista tulee ajan myötä yhä vähemmän informatiivisia. Tämän ongelman ratkaisemiseksi käytämme inline-pakkaustilastojen muutoksen määrää (deltaa) ja raportoimme pakkauksen vain tietyiltä aikaväleiltä. Taustalla oleva lähestymistapa on, että MTree-inline-pakkaustilastot tallennetaan säännöllisesti lokiin. Kun asiakas tekee MTree-pakkauskyselyn MSC-komennolla, laskemme luvun deltat lokin avulla pakkausraportointia varten. MSC raportoi oletuksena pakkauksen viimeisten 7 päivän ja 24 tunnin ajalta, vaikka mikä tahansa kiinnostuksen ajanjakso voidaan määrittää.
Oletetaan ensin, että MTree A:lle kirjataan seuraava loki:
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
Sitten MTree A: n pakkaus tälle tunnille on:
g_comp = (12000-11000)/(200-100) = 10x l_comp = (200-100)/(100-50) = 2x overall compression ratio = (12000-11000)/(100-50) = 20x
Yllä oleva pakkaussuhteen laskenta ei tee mitään tietojoukon koon kanssa. Esimerkiksi yllä olevassa mtreessä voi olla vain 500 Gt loogisia tietoja.
MSC tukee vaihtoehtoja "daily" ja "daily-detailed", samoin kuin "filesys show compression" -komentoa. Kun daily-asetus on määritetty, komento ilmoittaa päivittäisen pakkauksen kalenterin mukaisesti. Se laskee päivittäisen pakkaussuhteen raw_bytes ja post_lc_size-koon päivittäisen deltan avulla. Kun "daily-detailed" on määritetty, komento näyttää kaikki kolme deltaa (vastaavasti raw_bytes, pre_lc_size ja post_lc_size) kullekin päivälle; Se laskee myös g_comp ja l_comp kokonaispakkauskertoimen rinnalla.
Näiden järjestelmien näytetulokset ovat liitteessä.
3.3 Järjestelmän pakkaus
Kun ymmärrämme, miten pakkaus raportoidaan MTreesissä, on yksinkertaista laajentaa käsite koko järjestelmään. Järjestelmänlaajuinen pakkausinline-tilastojen kerääminen ja raportointi ovat täsmälleen samat kuin MTreesissä. Ainoa ero on laajuus, koska yksi on tietyssä MTreessä, kun taas yksi on koko järjestelmässä. Tulokset voi tarkistaa komennolla filesys show compression. Esimerkki tästä on kohdassa 2. Järjestelmän kompressio "viimeiset 7 päivää" ja "viimeiset 24 tuntia" ilmoitetaan FSC-tulosteen tulososion kahdella viimeisellä rivillä.
DD:issä, joissa on otettu käyttöön pilvitaso, tallennustila on jaettu aktiiviseen tasoon ja pilvitasoon, jotka ovat kaksi itsenäistä deduplikointitoimialuetta. Käyttäjät voivat lisätä tietoja vain aktiiviselle tasolle. Myöhemmin DDOS-tiedonsiirtotoimintoja voidaan käyttää tietojen siirtämiseen aktiiviselta tasolta pilvitasolle. Siten tilan ja puristuksen mittaus ja raportointi hoidetaan itsenäisesti kullakin tasolla. Tiedostotasolla emme kuitenkaan erottele tason mukaan ja raportoimme sisäisiä pakkaustilastoja. ne ovat täsmälleen samat kuin kohdassa 3.1 kuvatut tiedot.
Viimeinen korostettava aihe on joitakin deduplikoinnin ominaisuuksia, jota kutsutaan monissa Data Domain -asiakirjoissa "globaaliksi pakkaukseksi". Vaikka se sisältää sanan "pakkaus", se on täysin erilainen kuin perinteinen pakkauksen käsite, jota myös DDOS tarjoaa nimellä "paikallinen pakkaus".
Paikallinen pakkaus pienentää datan kokoa käyttämällä tiettyä algoritmia (tietyntyyppiset tiedot eivät ole puristettavissa ja pakkausalgoritmien soveltaminen niihin voi hieman lisätä datan kokoa). Yleensä, kun algoritmi on päätetty, itse data on pakkaussuhteen ainoa tekijä.
Deduplikointi on kuitenkin erilainen - se ei ole paikallinen käsite, se on "globaali". Saapuvan datasegmentin deduplikointi poistetaan kaikista olemassa olevista datasegmenteistä toimialueella, joka sisältää kaikki muiden kuin pilven Data Domain -järjestelmien tiedot. Itse datasegmentillä ei ole merkitystä deduplikointimenettelyssä.
Käytännössä tietojoukon ensimmäisessä varmuuskopioinnissa havaitaan harvoin suurta deduplikointisuhdetta. Ensimmäisissä varmuuskopioissa tietojen määrän väheneminen johtuu usein paikallisesta pakkaamisesta. Kun myöhemmät varmuuskopiot saapuvat Data Domainiin, deduplikointi osoittaa vahvuutensa ja siitä tulee hallitseva pakkaustekijä. Tieto-optimoinnin tehokkuus perustuu siihen, että tietojoukon muutosnopeus varmuuskopioinnista varmuuskopiointiin on alhainen. Tästä syystä tietojoukkoja, joilla on suuri muutosaste, ei voida hyvin poistaa. Kun varmuuskopiointisovellus lisää omia metatietopalojaan (joita Data Domain kutsuu markkereiksi) varmuuskopiokuviin suurella taajuudella, se ei myöskään välttämättä saa hyvää deduplikointisuhdetta. Merkkien käsittelytekniikkamme voivat auttaa joskus, mutta eivät aina.
Mitä voimme odottaa näiden havaintojen perusteella?
Pakkauksen mittaaminen on vaikeaa deduplikoiduissa tiedostojärjestelmissä, mutta vielä vaikeampaa se on log-rakenteisissa deduplikoiduissa tiedostojärjestelmissä. Meidän on ymmärrettävä, miten deduplikointi toimii ja miten pakkaustilastoja seurataan. Pakkaussuhteet ovat hyödyllistä tietoa tietyn järjestelmän käyttäytymisen ymmärtämiseksi. Järjestelmän tehokas puristussuhde on tärkein, luotettavin ja informatiivisin mittaus. Myös sisäiset pakkaustilastot voivat olla hyödyllisiä, mutta joissakin olosuhteissa ne saattavat olla vain heuristiikkaa.
Lisäys: Näytteen tuotos "mtree show compression" Oletetaan
, että MTree sisältää 254792,4 GiB dataa. Se on saanut 4379,3 GiB uutta tietoa viimeisten 7 päivän aikana ja 78,4 GiB viimeisen 24 tunnin aikana (muut aikavälit voidaan määrittää). Päivittäinen (daily) -optio ilmoittaa pakkauksen inline-tilastot viimeisten 33 päivän ajalta. Kun "päivittäinen yksityiskohtainen" -vaihtoehto tarjotaan, kokonaispuristussuhteet tarkennetaan jakamalla ne yleisiin ja paikallisiin puristussuhteisiin.
Mtree-luettelon tulos:
# 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)
------------- -------- --------- ----------- ---------- -------------
"Daily"-vaihtoehdolla:
# 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
"Daily-detailed" -vaihtoehdolla:
# 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