ZFS – Käyttöönotto

ZFS:ää evaluoidessa keskityttiin lähes kokonaan deduplikointiin, mutta samalla, lähes huomaamatta ZFS:ää rasitettiin melkoisesti ja tutkittiin erilaisten säätöjen vaikutuksia. Testiaineistossa oli yli 1,6 miljoonaa tiedostoa ja kokoa noin 8 teraa. Sen kopiointi oli odotettua hitaampaa, mutta 1 Mbps Ethernetkin on niin hidas, että kopiointiin menee vähintään 22 tuntia.

Levypooli uusiksi

Evaluoidessa levypooli ei ollut vielä siinä kokoonpanossa kuin halusin sen olevan lopullisena. Yksi 2 Tt levy ei ollut mukana poolissa ja raidz3 pitäisi vaihtaa raidz2:ksi. Tässä tapauksessa ei ole muuta tehtävissä kuin poistaa vanha pooli ja luoda uusi. Kopiointi menee myös uusiksi, valitettavasti.

root@rk6:~# zpool destroy tank
root@rk6:~# zpool create -f tank raidz2 c6t0d0 c6t1d0 c8t1d0 c12t50024E9203F93266d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0

Koska pooli poistettiin, menetettiin myös samalla kaikki tehdyt asetukset. Nostetaan välimuistin koko kahteen gigaan, säilötään siellä vain metadataa ja nopeutetaan suurten tiedostomäärien kirjoitusta:

root@rk6:~# echo ”arc_meta_limit/Z 0x80000000” |  mdb -kw
root@rk6:~# zfs set primarycache=metadata tank
root@rk6:~# zfs set logbias=throughput tank

Primarycache-asetus pitää muuttaa kopioinnin valmistuttua. Jos lokille annetaan oma laite, sillä saadaan nopeutta lisää. Käytetään nopeaa USB-tikkua:

root@rk6:~# rmformat
Looking for devices…
     1. Logical Node: /dev/rdsk/c1t0d0p0
        Physical Node: /pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0
        Connected Device: JetFlash Transcend 8GB    1.00
        Device Type: Removable
        Bus: USB
        Size: 7,5 GB
        Label:
        Access permissions: Medium is not write protected.
root@rk6:~# zpool add tank log /dev/rdsk/c1t0d0p0
cannot use ’/dev/rdsk/c1t0d0p0’: must be a block device or regular file
root@rk6:~# rmmount /dev/rdsk/c1t0d0p0
warning: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory
root@rk6:~# rmmount ’/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0’
warning: Failed to connect to socket /var/run/dbus/system_bus_socket: No such file or directory

Ei jostain syystä onnistu. Yritetään vielä.

root@rk6:~# ls /dev/dsk/c1t0d0p0 -l
lrwxrwxrwx 1 root root 59 2012-01-01 12:07 /dev/dsk/c1t0d0p0 -> ../../devices/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0:q
root@rk6:~# ls -l /devices/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0:q
brw-r—– 1 root sys 83, 912 2012-01-01 12:07 /devices/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0:q
root@rk6:~# zpool add tank log /devices/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0:q

Hieman outoa..

Lisätään vielä SSD-levy poolin välimuistiksi. En usko, että siitä on apua, mutta sen voi poistaa menettämättä poolia, joten lisäämisestä ei ole haittaakaan.

root@rk6:~# zpool add -f tank cache /dev/dsk/c0t2d0s2
root@rk6:~# zpool list tank
NAME   SIZE  ALLOC   FREE    CAP  DEDUP  HEALTH  ALTROOT
tank  18,1T   224G  17,9T     1%  1.00x  ONLINE  –
root@rk6:~# zpool status -v tank
  pool: tank
 state: ONLINE
 scrub: none requested
config:

        NAME                                                      STATE     READ WRITE CKSUM
        tank                                                      ONLINE       0     0     0
          raidz2-0                                                ONLINE       0     0     0
            c6t0d0                                                ONLINE       0     0     0
            c6t1d0                                                ONLINE       0     0     0
            c8t1d0                                                ONLINE       0     0     0
            c12t50024E9203F93266d0                                ONLINE       0     0     0
            c12t50024E90049E53C0d0                                ONLINE       0     0     0
            c12t50024E90049E5373d0                                ONLINE       0     0     0
            c12t50024E90049E5393d0                                ONLINE       0     0     0
            c12t50024E90049E5399d0                                ONLINE       0     0     0
            c12t50024E90049E5531d0                                ONLINE       0     0     0
            c12t50024E90049E5533d0                                ONLINE       0     0     0
        logs
          /devices/pci@0,0/pci1043,815a@2,1/storage@1/disk@0,0:q  ONLINE       0     0     0
        cache
          c0t2d0s2                                                ONLINE       0     0     0

errors: No known data errors

Root-oikeudet NFS-jakoihin

NFS-jaot määritellään komennolla ”zfs set sharenfs=on|off ”. Man-sivulla zfs ei kuitenkaan kerrota, miten oikeuksia voisi määritellä ja pitää olla hyvin tarkkaavainen, jotta huomaa viittauksen man-sivulle share, jossa taas viitataan kätevästi sivulle share_nfs. Komento, jolla lisätään root-oikeudet kahdelle koneelle:

share -F nfs -o rw,root=rk7:rk2 /tank

Linux-koneella on hyvä ottaa huomioon nfs:n versio ja sitten vain kopioimaan:

[root@rk7 mirrors]# mount -t nfs4 192.168.0.16:/tank /rk6
[root@rk7 mirrors]# time rsync -avH –progress /mirrors /rk6

Se ei valmistu ihan heti..

Deduplikoinnista jälleen

Slashdotissa oli aiheeseen liittyvä kysymys äskettäin: http://ask.slashdot.org/story/12/01/04/1955248/ask-slashdot-freeopen-ded… . Vastauksissa aika paljon toistettiin huomioitani. Mielenkiintoisia olivat Matt Dillonin kirjoitukset HAMMER-tiedostojärjestelmässä olevasta deduplikoinnin toteutuksesta. Se deduplikoi sekä on-line että off-line. On-line silloin, jos duplikaatti tarkistussumma sattuu olemaan välimuistissa ja loput off-line. HAMMER:ssa joudutaan myös poistettujen tiedostojen käyttämä tila vapauttamaan off-line, joten sen ”huolto” täytyy joka tapauksessa tehdä ajastetusti. Toinen varsin järkevältä kuulostava ominaisuus oli se, että deduplikointi voidaan jakaa osiin, jolloin keskusmuistivaatimus pienenee. Kääntöpuolena tästä on, että jokaista osaa kohden levytila pitää lukea uudelleen. Matt Dillon kirjoitti mainitussa slashdot-keskustelussa, että deduplikointi maksaa aina, joko muistin tai levy-IO:n määrässä. Tosin ZFS ei tarjoa yhtä hyvää kompromissia kuin HAMMER. SSD-levyn välimuistina on kuitenkin hyvä kompromissi ja sen ZFS tarjoaa.

Ennen kuin enemmän innostuu HAMMER:sta, pitää mainita, että se on DragonFly BSD:tä varten kehitetty tiedostojärjestelmä.
DragonFly BSD on FreeBSD:stä eriytynyt haara ja sillä on vähemmän kehittäjiä kuin FreeBSD:llä. Melko marginaalinen käyttöjärjestelmä siis. Toisaalta wikipedian ( http://en.wikipedia.org/wiki/DragonflyBSD ) mukaan siinä on melko mielenkiintoisia ominaisuuksia. Todennäköisin kompastuskivi ja mahdollisesti melkoisen arviointityön aiheuttava kysymys olisi levyohjainten laiteajurit ja niiden laatu. HAMMER:lla on oma sivu wikipediassa: http://en.wikipedia.org/wiki/HAMMER . HAMMER on myös alustavasti portattu Linuxiin, sen verran, että sitä pystyy lukemaan, ei kirjoittamaan. Sillä voi olla ehkä hyväkin tulevaisuus.

Tästä onkin hyvä jatkaa tiedostojärjestelmien vertailuun.

Suppea edistyksellisten tiedostojärjestelmien vertailu

Aluksi syy ZFS:stä kiinnostumiseen oli sen skaalautuvuus, koska ext4:n rajoituksena oli 16 Tt osion maksimikoko. Sen jälkeen kiinnosti deduplikointi, mutta kun se ei minun tarpeisiini sovi, on vikasietoisuus noussut tärkeäksi. Wikipedian sivulla, jossa luetellaan tiedostojärjestelmiä ( http://en.wikipedia.org/wiki/List_of_file_systems#File_systems_with_buil… ), on vikasietoisiksi tiedostojärjestelmiksi luokiteltu vain viisi tiedostojärjestelmää. Btrfs on vielä keskeneräinen. HAMMER jo oikeastaan käsiteltiin ja Reliance sekä Reliance Nitro ovat tarkoitettu sulautettujen järjestelmien flash-muisteille.

Vikasietoisuudesta vielä hieman. Wikipedian sivu http://en.wikipedia.org/wiki/ZFS#Data_Integrity luettelee syitä, miksi se on tärkeää. Ne voivat kuulostaa kaukaa haetuilta, mutta minulla on ”bittimädästä” kokemusta. Sivulla http://www.raimokoski.com/testialue.shtml otsikon ”Varoitus uusien kerneleiden IDE-kiintolevyjen ajurien vioista” kerrotaan Red Hat 8.0:n kernelin IDE-ajurien tavasta ajoittain, ja hyvin harvoin kirjoittaa levylle väärää sisältöä. Vikaa esiintyi vain tietyissä laitekokoonpanoissa, joten sen tarkempi etsiminen olisi ollut melko vaikeaa.

Muistan myös toisen samantyyppisen ongelman melko tarkkaan samoilta ajoilta. Spectra Linux 1.2:n eräs oheis-CD käytti zisofs:ää eli pakattua CD:n tiedostojärjestelmää, jotta sille saatiin mahtumaan noin 1,2 Gt tiedostoja. Kun sen käyttöä testattiin, tuli lukuvirheitä noin 20 kpl, mutta aina eri kohdissa levyä. Mystisemmäksi asian teki se, että jos koneessa oli AMD:n prosessori, tuli lukuvirheitä vain noin 4 kpl luettaessa koko levy. Pari viikkoa vian paikantamisessa ja korjaamisessa meni. Ratkaisu oli poistaa Alan Coxin tekemästä melko massiivisesta kernelin patch-tiedostosta vanhan zlib-koodin korvaava koodi, joka oli luokiteltu alpha-tasoiseksi. Tein saman poiston myös pakatun ytimen purkavasta koodista ja jostain vähemmän kriittisestä kolmannesta paikasta. Myös edellä mainittu IDE-levyihin liittyvä ongelma johtui Alan Coxin koostamasta patchistä.

Bittimätää siis esiintyy. Kuitenkin erittäin harvoin ja epätodennäköisesti. Lisäksi niin väitettäessä on syytä olla erittäin hyvät todisteet tai sinua ei uskota asiantuntevimmissa piireissä. Edellä kertomistani tapauksista on lähes 10 vuotta, mutta opetus on silti kirkkaana mielessä: tallennettu tieto on vasta silloin tallessa, kun se ja sen tarkistussumma luettaessa täsmäävät.

Jos vikasietoisuus on tärkeä, ei tällä hetkellä näytä olevan käytännössä muita luotettavia tiedostojärjestelmiä kuin ZFS. Tämä näkymä on kuitenkin osittain väärä. Useimmat tiedostojärjestelmät eivät ota kantaa laitteistotason luotettavuuteen. Se on joko rauta. tai softa-RAID:in tehtävä. Oikea johtopäätelmä on, että ZFS on ainoa luotettava tiedostojärjestelmä, johon on intregroitu myös RAID:n ja LVM:n toiminnallisuus.

Linuxin tiedostojärjestelmien tulevaisuudesta

Tällä hetkellä lähes kaikkien uusien Linux-levitysversioiden oletustiedostojärjestelmä on ext4. Se olisi kelvannut minullekin, mutta ext2fsprogs rajoitti sen kooksi 16 Tt. Arviointiprosessin aikana tämä kokorajoitus on kuitenkin rikottu. Marraskuussa 2010 julkaistu ext2fsprogs versio 1.42:ssa rajoitusta ei enää ole ja uusi raja on ilmeisesti 1 exatavua. Exatavun ja teratavun välissä on petatavu, joten ihan heti uusi rajoitus ei käytännössä tule vastaan.

Ext4 ei kuitenkaan sen tekijän Ted Ts’o:n mukaan ole tulevaisuuden tiedostojärjestelmä vaan Btrfs. Ext4 on ihan hyvä yleistiedostojärjestelmä ainakin toistaiseksi ja brtfs vaikuttaa etenevän hyvää tahtia. Sen pääkehittäjä Chris Mason työskentelee Oraclelle ja brtfs:n on tarkoitus olla oletustiedostojärjestelmä Oraclen Linuxissa lähitulevaisuudessa. Myös Red Hat ja monet muut levitysversioiden tekijät ovat mukana sen kehityksessä. Btrfs on Red Hat Enterprise Linux 6.0:ssa mukana, mutta technology preview -tyyppisenä eli sitä ei tueta ja se saattaa puuttua uudemmista versiosta. Eräs brtfs:n hieno ominaisuus on, että ext3/4 tiedostojärjestelmä voidaan muuntaa btrfs:ksi. Huonoja puolia taas on esimerkiksi pariteetillisten RAID-tasojen puute. Tällä hetkellä se osaa vain RAID-tasot 0, 1 ja 10. RAID 5 ja 6 on luvassa myöhemmin.

Minä jatkan kuitenkin ZFS:n käyttämistä. Olen jo nyt investoinut sen tutkimiseen melko paljon aikaa. Jos ennen siihen tutustumista ext4:n kokorajoitus olisi ollut selvästi suurempi kuin 16 Tt, en todennäköisesti olisi vaivautunut. Tuntemattomissa tiedostojärjestelmissä on aina se vaara, että niistä paljastuu jokin puute tai rajoitus. Tästäkin on kokemusta. Silloin, kun journaloivat tiedostojärjestelmät tekivät tuloaan Linuxiin, testasin ReiserFS:ää, XFS:ää ja JFS:ää. JFS:n kanssa tuli ongelma, kun piti kirjoittaa yli 70 000 tiedostoa samaan hakemistoon. En muista varmasti antoiko se virheilmoituksen eikä jatkanut vai hidastuiko se käyttökelvottomaksi. Joka tapauksessa tiedostojen määrällä oli naurettavan pieni yläraja. Tämä puute on myöhemmin varmasti korjattu.

Seuraavalla kerralla

Tiedostojen kopionti on sujunut suhteellisen ripeästi, mutta on vielä kesken. Nyt kiinnostaa kuinka paljon lokitiedoston siirto omalle laitteelleen nopeuttaa ja SSD-levyn vaikutus. Kopionnin valmistuttua niitä on hyvä testata. On nimittäin paljon mielenkiintoisempaa testata melko täydellä tiedostojärjestelmällä kuin lähes tyhjällä, sillä silloin testiympäristö vastaa todellista käyttötilannetta.