ZFS:n evaluointia – 1. 1. 2012

Vihdoin tulokset ja johtopäätelmät. Eilen tuli tieto miten paljon blokkitason deduplikoinnilla säästäisi levytilaa. zdb teki töitä yli 40 tuntia sen laskemiseksi. Ilman huippunopeaa SSD-levyä aikaa olisi kulunut moninverroin enemmän. Muistia zdb tarvitsi yli 28 Gt. Analysoitavan tiedostojärjestelmän tiedot zdb luki ja esikäsitteli noin 17 tunnin aikana, jonka jälkeen se ei enää varannut lisää muistia.

Täytyy tunnustaa, että tämä on eräs tyhmimmistä jutuista, joita olen tietokoneella tehnyt. OpenSolaris-koneeni emolevy tukee korkeintaan 4 Gt keskusmuistia ja sen verran sitä jo on. Silti halusin ajaa ohjelmaa, joka vaati 28 Gt muistia. Se oli tietysti hidasta. Toisaalta virheistä oppii ja tämä oli myös mielenkiintoinen kokeilu, miten SSD-levyllä pystyy melko tyydyttävästi jatkamaan keskusmuistia.

Jaarittelut sikseen, zdb:n ja time:n tulosteet:

Simulated DDT histogram:

bucket              allocated                       referenced         
______   ______________________________   ______________________________
refcnt   blocks   LSIZE   PSIZE   DSIZE   blocks   LSIZE   PSIZE   DSIZE
——   ——   —–   —–   —–   ——   —–   —–   —–
     1    54.5M   6.75T   6.75T   6.74T    54.5M   6.75T   6.75T   6.74T
     2    2.22M    257G    257G    256G    4.79M    554G    554G    553G
     4    66.6K   5.20G   5.20G   5.21G     323K   25.9G   25.9G   25.9G
     8    15.2K   1.10G   1.10G   1.11G     141K   9.93G   9.93G   9.97G
    16    4.48K    494M    494M    494M    99.7K   10.9G   10.9G   10.9G
    32      309   5.75M   5.75M   6.01M    12.9K    259M    259M    270M
    64      279   26.0M   26.0M   26.0M    20.6K   1.81G   1.81G   1.81G
   128       34    498K    498K    523K    5.68K   78.5M   78.5M   82.8M
   256       14    434K    434K    442K    4.78K    134M    134M    137M
   512        5    148K    148K    150K    3.17K   81.3M   81.3M   83.0M
    1K       12   6.50K   6.50K   17.1K    15.7K   8.53M   8.53M   22.4M
    2K        4      2K      2K   5.27K    9.48K   4.74M   4.74M   12.5M
    1M        1    128K    128K    128K    1.65M    211G    211G    211G
 Total    56.8M   7.01T   7.01T   6.99T    61.6M   7.55T   7.55T   7.53T

dedup = 1.08, compress = 1.00, copies = 1.00, dedup * compress / copies = 1.08

real 40:31:11.9
user    20:58.7
sys   1:00:19.5

Tuloksen saamista ei hidastanut pelkästään keskusmuistin vähyys. Tapaninpäivän myrsky aiheutti sähkökatkoja ja zdb piti käynnistää uudelleen alusta. Vielä senkin jälkeen tuli lyhyt sähkökatko ilmeisesti sähköverkon korjaustöiden takia ja silloin zdb oli ehtinyt tehdä töitä jo 31 tunnin ajan. Tästä suivaantuneena laitoin uudet akut niitä jo jonkin aikaa odottaneeseen UPS:iin ja kytkin OpenSolaris-koneen siihen. Vähän sen jälkeen, kun olin antanut käskyn ”nohup time zdb -S tank” ssh-sessiossa, tuli taas lyhyt sähkökatko, mutta silloin siitä ei enää ollut haittaa. Kaiken kaikkiaan vaatimattoman tuloksen saamiseen meni yli 5 päivää.

Deduplikoinnin käyttöä suositellaan, jos sen avulla saadaan levytilan käyttö vähintään puolitettua eli deduplikointisuhde on vähintään kaksi. Testiaineistolla se olisi vain 1,08 ja levytilaa säästyisi 0,5 teraa. Jos kiintolevyjen hinnat olisivat normaalilla tasolla eikä Thaimaan tulvien nostamat, maksaisi 0,5 teraa noin 50 Euroa. Niin pienen summan takia ei kovin suurta vaivaa kannata nähdä tai kärsiä huomattavasta hidastumisesta.

Jos levytilaa kuitenkin haluttaisiin säästää, on muitakin keinoja kuin ZFS:n deduplikointi. Kuten jo tämän kirjoitussarjan ensimmäisessä osassa todettiin, voidaan käyttää myös tiedostotason deduplikointia, joka on käytännössä pakko toteuttaa off-line-tyyppisesti, josta seuraa se etu, että se voidaan käynnistää silloin, kun koneen kuormitus on vähäisintä. Lisäksi samaa keinoa voidaan käyttää myös muissa käyttöjärjestelmissä ja tiedostojärjestelmissä, jotka tukevat kovia linkkejä.

Kovat linkit aiheuttavat tosin pieniä ongelmia tiedostoja kopioitaessa. Jos niitä ei ota huomioon, kirjoittuu useasti linkitetty tiedosto kohteeseen niin monta kertaa kuin siihen on linkkejä. Tavallaan tämä ei ole ongelma, levytilaa vain kuluu enemmän. Toinen ongelma on, että sellaisia ohjelmia, jotka ottavat kovat linkit huomioon, on vähän. Esimerkiksi vakio kopiointikäsky ”cp” kopioi tiedostojen sisällön eikä tee kovia linkkejä. rsync on parempi, mutta sekin kopioi ensin tiedostot ja vasta sen jälkeen korvaa useasti linkitetyt kovilla linkeillä (tämä käytös riippuu todennäköisesti versiosta).

Entä sitten tiedostotason deduplikoinnin tilan säästö. Tein jo aikaisemmin siitä laskelman, mutta myös hardlink-ohjelma osaa antaa arvion säästöstä:

# hardlink -cnv /mirrors
Directories 165197
Objects 1799681
IFREG 1495295
Mmaps 549385
Comparisons 30348943
Would link 515368
Would save 294944960512

Säästöä tulisi siis 275 Gt, jos vertaillaan vain tiedostojen sisältöä, ei oikeuksia, omistajuutta tai muita eroja. Jos myös tiedostojen metadatojen pitää olla samoja, antaa tuloksen komento:

# hardlink -nv /mirrors
Directories 97075
Objects 924214
IFREG 737291
Mmaps 302969
Comparisons 344861
Would link 293144
Would save 59131146240

55 Gt on ehdottomasti liian vähän aiheuttamaan mitään toimenpiteitä, eikä edes 275 Gt innosta.

Minkä tyyppiset tiedostot deduplikoituvat parhaiten?

Testiaineistosta lähes 7 Tt on videotiedostoja. Useat ovat TV-lähetyksien tallenteita, myös kaupallisilta kanavilta. Niistä olisi teoriassa poistettavissa esimerkiksi mainosten duplikaatit, mutta ZFS ei siihen pysty. Se missä kohtaa tiedostoa mainos on, on lähes sattumanvarainen eikä se käytännössä koskaan osu blokkirajalle. Sama ongelma on ohjelmien uusinnoissa. Vaikka tallentava kone olisi lähes atomikellon tarkkuudella oikeassa ajassa ntp-palvelimien ansiosta, eivät lähetysajat ole tarkkoja. DVD-levyiltä kopioitujen elokuvien duplikaatit varmaankin deduplikoituisivat, mutta niitä tuskin samaan päähakemistoon kertyy, jos nimeämiskäytäntö on säännönmukainen. Videot eivät siis deduplikoidu.

Musiikkitiedostoista voi sanoa samaa kuin videoista lähes samoin perustein, ne eivät deduplikoidu.

Testiaineistossa oli vielä noin teratavu muita kuin video- ja musiikkitiedostoja. Se koostuu pääasiassa muiden Linux-koneiden ja kiintolevyjen varmuuskopioista. Tämä selittää melko valtaisan tiedostomäärän. Kyseiset hakemistot voisi pakata myös arkistoihin, mutta niin suurten arkistojen käsittely on melko hankalaa. Näiden hakemistopuiden yhteiskoko on 457 Mt ja hardlink sanoi niistä seuraavaa:

[root@rk7 mirrors]# hardlink -cnv laptop c52 fc12 Fedora-10-i386 hda3 hdg1 rk22bak rk22root rk22usrsrc rk22usrsrc2 rk4root rk4usrlocal www.raimokoski.com
Directories 159188
Objects 1712714
IFREG 1417217
Mmaps 536803
Comparisons 30336535
Would link 503470
Would save 93539250176

Säästö olisi 87 Mt eli reilu 20 %. Oikeastaan tämä on varsin hyvin huomioon ottaen sen, että käytetyt Linux-versiot ovat hyvin eri ajoilta. Täytyy kuitenkin todeta, että testiaineistossa ei ole mitään runsaasti deduplikoituvaa kokonaisuutta.

Mitkä sitten olisivat hyvin deduplikoituvia kokonaisuuksia? Jo mainitut varmuuskopiot, mutta enemmän saman sisältöisistä koneista. Vielä parempi esimerkki on chroot-hakemistopuut ja chroot-tyyppisten virtualisointijärjestelmien hakemistopuut. Niissä uniikkia sisältöä voi olla voi olla hyvinkin vähän ja lähes identtisiä hakemistopuita kymmenittäin. Helpoimpia esimerkkejä on rpm-paketti bind-chroot, jossa on jo hyödynnetty kaikki mahdollinen tilansäästö. Fedora 13:n versiossa sen tiedostojen yhteenlaskettu koko on 0 tavua!

# rpm -qi bind-chroot-9.7.0-10.P2.fc13.x86_64
Name        : bind-chroot                  Relocations: /var/named/chroot
Version     : 9.7.0                             Vendor: Fedora Project
Release     : 10.P2.fc13                    Build Date: to 20. toukokuuta 2010 15.07.16
Install Date: la 19. kesäkuuta 2010 16.16.42      Build Host: x86-04.phx2.fedoraproject.org
Group       : System Environment/Daemons    Source RPM: bind-9.7.0-10.P2.fc13.src.rpm
Size        : 0                                License: ISC
…

Miten deduplikoinnin edut saadaan parhaiten käyttöön ja haitat minimoidaan?

Deduplikointi voidaan ottaa käyttöön vain osassa poolia. Komennolla ”zpool create ..” luodaan samalla poolin (ja zfs:n) juurihakemisto, mutta sen alle voidaan luoda dataset-tyyppisiä hakemistopuita, joiden ominaisuuksista osa voi poiketa juurihakemistosta. Uusi dataset perii oletusominaisuudet joko juuresta tai ylemmältä datasetiltä. Uusi dataset luodaan käskyllä ”zfs create [/väli-dataset]/” ja esimerkiksi deduplikoinnin käyttöä ohjataan komennolla ”zfs set dedup=on|off ”.

Paras käytäntö on siis luoda oma dataset eli alihakemisto joko ei-deduplikoituvalle tai deduplikoituvalle materiaalille tai molemmille ja asettaa dedup-arvo tarpeen mukaan. Lisäksi olisi hyvä etukäteen arvioida melko tarkkaan duduplikoituvan osuuden koko, koska se vaikuttaa rajusti muistivaatimuksiin ja muihin resurssivaatimuksiin, joita edellä olemme nähneet.

Johtopäätelmät

Deduplikointi tarjoaa jotain taianomaista: ilmaista, runsasta ja automaattista säästöä. Tarkemmassa tarkastelussa ilmaisuus kuitenkin häviää hyvin nopeasti eikä automaattisuuskaan ole kovin kaukana käsikäyttöisyydestä. Runsaus on tapauskohtaista ja aika harvinaista.