Esipuhe

ZFS eli Zettabyte File System on 128-bittisenä käsittämättömän skaalautuva. Linuxin vakiotiedostojärjestelmässä ext4:ssä raja on surkea 16 Tt. ZFS:ssä kiinnostaa se, ettei se lopu kesken ja lisäksi sen muut hienot ominaisuudet, kuten deduplikointi.

Tämä kirjoitus on koottu Uuden Suomen vapaavuoro-blogiin kirjoittamistani jutuista. Tekstiä ei ole juurikaan muutettu, mutta järjestystä on muutettu loogisemmaksi. Osa eroista johtuu siitä, että vapaavuorossa on rajoitetut keinot käyttää esimerkiksi otsikkotasoja ja sijoitella kuvia.

Otsikoiden jälkeen usein esiintyvä päiväys tarkoittaa alkuperäistä julkaisupäivämäärää.

ZFS:n dokumentointi

12. 2011

Tänään arvioin ZFS:n dokumentointia käyttäen esimerkkinä kysymystä: onko deduplikointi järkevää, jos se voi hidastaa levylle kirjoitusta dramaattisesti.

Olen jo aikaisemmin kertonut, että olen tehnyt samantapaista ZFS:n testausta ennenkin. Silloin deduplikoinnin käyttö alkoi hidastaa ZFS:n toimintaa lähes eksponentiaalisesti, kun oltiin ylitetty tietty levyn täyttöaste.

Ensin ajattelin kirjoittaa OpenSolarikseen ja erityisesti ZFS:ään liittyvästä dokumentaatiosta. Kehuin jo wikipedian ZFS-artikkelia ( http://en.wikipedia.org/wiki/ZFS#Deduplication ) ja ajattelin, että juuri tuo deduplikoinnin muistivaatimusta koskeva kysymys olisi hyvä pistokoe vertailla dokumentaatiota.

Niinhän se olikin. 310-sivuisessa kirjassa Oracle Solaris Administration: ZFS File Systems ( http://docs.oracle.com/cd/E23824_01/html/821-1448/index.html ) asia kyllä kerrotaan ( http://docs.oracle.com/cd/E23824_01/html/821-1448/gazss.html#gjhav ), mutta melko koukeroisesti eikä anneta selkeää esimerkkiä tai nyrkkisääntöä, kuten wikipedian artikkelissa. Wikipedian artikkelissa deduplikoinnin kohdalla oli myös viitteitä. Seurasin niitä ja ketju Summary: Dedup memory and performance (again, again) ( http://mail.opensolaris.org/pipermail/zfs-discuss/2011-July/049209.html ) zfs-discuss-postituslistalla antaa aika synkän kuvan deduplikoinnin vaikutuksesta suorituskykyyn. Edes runsas keskusmuisti ei riitä ja vaikka sitä olisi, pitää OpenSolariksen ytimen asetuksia muokata debuggerilla. OpenSolariksessa ei ole Linuxin tapaan /proc-tiedostojärjestelmää, jota kautta ytimen asetuksia voi tarkistaa ja muuttaa, joten aika hurjalta tuo näyttää. Ohje sivulla http://mail.opensolaris.org/pipermail/zfs-discuss/2011-May/048244.html ja testinä nykyisen arvon tarkistus:

Postituslistojen lukeminen jätti minut lähinnä hämmentyneeksi. SSD-levyn lisääminen cache-laitteeksi auttaisi, samoin ytimen asetusten säätö. Oraclen dokumentaatiosta löytyi kuitenkin tapa lähestyä samaa ongelmaa toiselta suunnalta. Komento:

kertoo kuinka paljon tilaa voitaisiin säästää, jos olisi käytetty deduplikointia ja/tai pakkausta ja kuinka paljon tiedoston ylimääräisten kopioiden tallennus sitä lisää. Yllä oleva tulos kertoo huikeasta säästöstä. Kaksi pelkkiä nollia sisältävää 40 Gt kokoista tiedostoa ei veisi juuri yhtään levytilaa, jos deduplikointi olisi käytössä.

Palataan dokumentoinnin arviointiin. Sivulla http://docs.oracle.com/cd/E23824_01/html/821-1448/gaypw.html#gfxtd on lause "Cache devices cannot be mirrored or be part of a RAID-Z configuration.", jonka voisi tulkita niin, että raidz-pooliin ei voi lisätä cache-laitetta. http://www.solarisinternals.com/wiki/index.php/ZFS_Best_Practices_Guide#... kuitenkin rauhoittaa: "it is not possible to mirror or use raidz on cache devices, nor is it necessary. If a cache device fails, the data will simply be read from the main pool storage devices instead."

Minun mielestäni wikipedian ZFS-sivu on paras. Se on melko lyhyt, mutta se kertoo olennaisen selkeästi. Sivustolla http://www.solarisinternals.com/wiki/index.php/Solaris_Internals_and_Per... on useita wiki-tyyppisiä ZFS:ää käsitteleviä oppaita. Minun tuntumani on, että sekin olisi parempi kuin Oraclen oma dokumentointi. Syvällisintä tietoa löytyy kuitenkin Oraclen työntekijöiden blogeista, kuten http://blogs.oracle.com/roch/entry/dedup_performance_considerations1 .

ZFS kyllä, mutta mikä käyttöjärjestelmä?

20.12. 2011

ZFS:ää voisi käyttää Linuxissakin, mutta Solaris on tullut tutuksi työelämässä ja OpenSolariksessa on muitakin hyviä ominaisuuksia. OpenSolariksesta ei kuitenkaan tule enää uusia versioita. Entä Oracle Solaris Express tai OpenIndiana tai sittenkin Debianin ja Illumosin ytimen yhdistävät Nexentastor ja Illumian?

Solariksen ehkä suosituin ominaisuus on virtualisointitekniikka, josta käytetään nimitystä zones ja aiemmin containers. Se on kaikkein tehokkain virtualisointitapa, koska se ei oikeastaan ole virtualisointia vaan vahvistettu chroot. Kaikki "virtuaalikoneet" käyttävät samaa ydintä, mutta eivät näe muiden muisti- ja prosessiavaruutta. Erikoistapauksena ovat ns. branded zones ja yksi niistä on Linux. OpenSolariksessa (en tiedä, onko sama mahdollista Solariksessa ja missä versiossa) on emulointikerros, jonka avulla sen ydin näyttää Linuxin ytimeltä. Varsin vahva ominaisuus siis.

Täytyy kuitenkin heti huomauttaa, että zones on jo vanha tekniikka ja vastaavia löytyy muillekin käyttöjärjestelmille. BSD:n jails pitäisi olla samanlainen ja Linuxille kaupallinen Parallels Virtuozzo Containers tai sen ilmaisversio OpenVZ. Wikipedian sivu  http://en.wikipedia.org/wiki/Operating_system-level_virtualization listaa luultavasti kaikki.

Crossbow on tavallaan virtualisoinnin jatke. Se on virtuaalinen verkkoympäristö. Sen avulla voi yhdessä koneessa rakentaa lähiverkon virtuaalikoneiden ja virtuaalikytkinten avulla.

ZFS:n deduplikointi sopii erittäin hyvin yhteen tämän tapaisen virtualisoinnin kanssa. Virtuaalikoneiden hakemistot pitää vain laittaa samaan levypooliin, jotta deduplikointi toimisi.

No, tarkastellaan eri käyttöjärjestelmävaihtoehtoja. Oracle Solaris Expressissä kiinnostavin on lisenssiehdot. Kun niitä etsii huomaa, että Oracle Solaris Expressiä ei enää mainita erillisenä tuotteena. Se on Oracle Solaris 11 sovelluskehittäjille tarkoitetulla OTN-lisenssillä: http://www.oracle.com/technetwork/licenses/solaris-cluster-express-licen... , jonka keskeisin kohta on:

"LICENSE RIGHTS
Except for any included software package or file that is licensed to you by Oracle under different license terms, we grant you a perpetual (unless terminated as provided in this agreement), nonexclusive, nontransferable, limited License to use the Programs only for the purpose of developing, testing, prototyping and demonstrating your applications, and not for any other purpose."

Tosin muualla lisätään ( http://www.oracle.com/technetwork/indexes/downloads/index.html#servers ):
"Developers:
All software downloads are free, and most come with a Developer License that allows you to use full versions of the products at no charge while developing and prototyping your applications, or for strictly self-educational purposes."

Huomaa lisäys "or for strictly self-educational purposes." Ehkä minun käyttötarkoitukseni laajasti tai vapaasti määritellen voisi käsittää täyttävän lisenssiehdot, mutta kun vaihtoehtoja on, jätän väliin. Tuote on kuitenkin ladattavissa sivulla http://www.oracle.com/technetwork/server-storage/solaris11/downloads/ind... , jos hyväksyy lisenssiehdot.

OpenIndianasta ei ole vielä valmista versiota. Tällä hetkellä uusin kehitysversio on 151a. Se on jaettu Desktop- ja Server-versioihin ja molemmat voi ladata sivun http://openindiana.org/ kautta. Desktop-version arvostelu löytyy sivulta http://www.linuxbsdos.com/2011/10/15/openindiana-151a-desktop-review/ . Vakaa versio on luvattu vielä tämän vuoden aikana eli ihan pian :)

OpenIndianan suurin uutuus on KVM, joka voi olla tuttu Linuxista. Se on "aito" virtualisointituote, jolla voi ajaa esimerkiksi Windowsia. Kuitenkaan aivan kaikkea toiminnallisuutta, joka on OpenSolariksessa, ei vielä ole valmiina OpenIndianan käyttämässä illumos-projektin tuottamassa ytimessä. Ei siis vielä ehkä kannata päivittää. Päivitysohjeet OpenSolariksesta OpenIndianaan löytyvät ( http://wiki.openindiana.org/oi/Upgrading+from+OpenSolaris ) ja niiden perusteella voisin vaihtaa OpenSolariksen käyttämän pkg-paketinhallintajärjestelmän ohjelmalähteeksi OpenIndianan ylläpitämän OpenSolaris snv_134 dev repositoryn. Oracle ei nimittäin enää tarjoa alkuperäistä, joten sieltä en voi asentaa lisäohjelmia OpenSolarikseen.

Johtopäätös on, että odotan vähintään vakaata OpenIndianan versiota ja tarkistan puuttuuko illumosin ytimestä tärkeitä ominaisuuksia.

Entä sitten NexentaStor ( http://www.nexentastor.org/ )? Suurimmat syyt minulle, miksi ei, ovat ilmaisen version 18 Tt kokorajoitus levytilalle, Debian-pohjaisuus ja tuotteen rajoittuneisuus yleensä. Sen verran olen tutustunut NextentaStorin dokumentaatioon, että voin sanoa sen käytön näyttävän helpolta. Jos haluaisin vain luotettavaa tallennustilaa, 18 Tt riittäisi enkä välittäisi tutustua aiheeseen syvemmin, valitsisin sen. En kuitenkaan halua luopua säätämisen hauskuudesta, joten ei.

Illumian on myös Nexentan projekti, joka ilmeisesti korvaa Nexenta Coren, joka on täysi käyttöjärjestelmä eikä pelkkä "storage appliancen" rajoitettu käyttöjärjestelmä kuten NexentaStor. Asensin kerran NexentaStorin ja ymmärsin käyttäjän pääsevän vain virtuaalikoneelle, ei "hardware noodiin" tai "global zonelle". Illumian ei ole julkaissut vielä mitään.

Laitteistosta – Kotelot, SATA/SAS-adapterit, port multiplier, SAS expander

12. 2011

ZFS antaa mahdollisuuden yhdistää vaikka kuinka monta levyä, mutta jossain vaiheessa fyysiset rajat tulevat vastaan. Tavalliseen täysimittaiseen tornikoteloon saa mahtumaan 12 kiintolevyä ilman kikkailua, mutta suunnilleen samankokoiseen koteloon on saatu mahtumaan jopa 48 kappaletta isoja 3,5 tuuman levyjä.

Konesaleissa kiintolevyt ovat perinteisesti olleet kelkassa, joka on ulosvedettävissä laitteen etuosassa. Sen tyyppiseen 4U korkuiseen räkkikoteloon mahtuu 24 isoa levyä. Sun esitteli kuitenkin vuonna 2007 toisen tyyppisen 4U kotelon, jossa levyt "tiputettiin" pystyssä kotelon päältä. Tietokoneen jutussa http://www.tietokone.fi/lehti/tietokone_4_2007/sun_fire_x4500_1352 väitettiin virheellisesti kotelon korkeuden olevan 2U. Siihen mahtui peräti 48 levyä. Tallennustilaa verkossa myyvä Backblaze suunnitteli saman tyyppisen kotelon ja julkisti sen piirustukset ohjeineen syksyllä 2009. Nyt siitä on julkaistu jo toinen paranneltu versio http://blog.backblaze.com/2011/07/20/petabytes-on-a-budget-v2-0revealing... . Pari vuotta sitten Sunin "Stomper" oli saanut muitakin matkivia seuraajia. Konesaleissa tila on kallista ja mitä pienempään tilaan levyt saadaan ahdettua, sitä edullisemmaksi se tulee. Tällä hetkellä päältä ladattavat kotelot ovat kuitenkin lähes kaikki hävinneet ja niiden tilalle on tulleet kotelot, joissa levykelkat ovat sekä edessä että takana. Supermicron SuperChassis 847E26-R1400UB:n ( http://www.supermicro.nl/products/chassis/4U/847/SC847E26-R1400U.cfm ) tyyppiset kotelot, joissa takaosan pinnasta puolet on varattu levykelkoille tulivat kuitenkin ensin. Niihin mahtui 36 kiintolevyä. Uudempaan SuperChassis 847E26-RJBOD1:een ( http://www.supermicro.nl/products/chassis/4U/847/SC847E26-RJBOD1.cfm ) on taakse jätetty kolmen levykelkan verran tilaa virtalähteille, joten levymäärä kasvoi 45:een. Päältä ladattava kotelo on sen takia hankala, että sen pitää olla kiskoilla ja tukevilla sellaisilla, koska esimerkiksi täyteen ladattu Backblaze painaa lähes 70 kiloa. Kiskot taas edellyttävät, että johdoissa on liikkumavaraa.

Ensimmäinen Backblazen ohjeiden mukaan itselleen koonnut oli harrastelija, jonka "Extreme Media Server" korvasi neljä aikaisempaa levypalvelinta. Backblazen avulla hän pystyy katsomaan 16:tta videota samaan aikaan! ( http://blog.backblaze.com/2009/10/12/user-builds-extreme-media-server-ba... ). Harrastelijoille on kuitenkin tarjolla kaikenlaista erilaista ulkoista koteloa ja kotelon lisuketta, kuten kehikkoja, joihin mahtuu lappeellaan neljä kiintolevyä ja kehikko taas mahtuu kolmeen 5 1/4" leveään levypaikkaan. Sillä saa yhden levypaikan lisää!

Backblazessa se ongelma, että moniporttiset SATA-adapterit ovat hävyttömän hintaisia ja halvempia käytettäessä lisäkorttipaikat loppuvat kesken, on ratkaistu kayttämällä port multiplier -piirejä. Moniporttiset SATA-adaperit ovat myös usein RAID-kortteja, joka taas ZFS:ää käytettäessä on täysin turha ominaisuus. Port multiplier -piirien avulla yhteen SATA-porttiin voidaan liittää Backblazessa 5 SATA-levyä. Jos käytetään SAS-väylää, on vastaava laajennustapa SAS expander. Esimerkiksi Supermicron AOC-USAS2-L8i tukee 63:a laitetta SAS expander -piirien avulla.  Suoraan AOC-USAS2-L8i:hin voidaan kytkeä 8 levyä ja koska se on niin halpa ( http://www.eco-finder.com :ssa alle 1000 Kr eli noin 100 €), kannattaa ennemmin hankkia niitä useampi niin kauan kuin pitkät PCI-e-paikat emolla riittävät. Suoraan kytkemisessä on myös se etu, että useampi levy samassa portissa tukkisi pian väylän. ZFS:n luontivaiheessa ei sentään välittömästi aleta laskea pariteettia, kuten Linuxin pariteetillisiä RAID-tasoja käytettäessä, mutta sille suositellaan viikottaiseksi huoltotoimenpiteeksi scrub-operaatiota, joka vertaa tarkistussummia tallennettuihin tiedostoihin ja tämä operaatio voi olla hyvinkin hidas tukkoisilla väylillä.

Supermicron 8-porttinen SAS-kortti. Suoja/kiinnityspelti, joka näkyisi oikealla, on poistettu, koska se on oikeassa paikassa vain AOC-tyyppisissä koteloissa - Supermicron ikioma standardi. AOC-kortit sopivat silti normaaliin PCI-e-väylään. Vasemmalla on kaksi SFF8087-liitintä. Niihin sopiva kaapeli haarautuu neljäksi normaaliksi SAS/SATA-kaapeliksi. Suomessa ainoa ostospaikka on Damicon Kraa ( http://www.damicon.fi ), mutta itse olen tilannut Ruotsista ( http://eco-finder.com/shop/ ). Kannattaa tilata kaapelit samalla, niitä ei joka paikasta löydy.

10/100-megainen verkkokortti ja AOC-kortti, johon on kiinnitetty toisesta verkkokortista suojapelti. Alla on OpenSolaris-koneen emolevyn manuaali.

Surffaillessa löytyi tieto, että Supermicro USAS2-L8i:lle löytyy suoja/kiinnityspelti, joka sopii tavalliseen PC-koteloon. Hinta on vain 1,3 €, mutta postitus maksaa pari kymppiä. Kaupan sivu on http://nz.mouser.com/ProductDetail/Keystone-Electronics/9203/?qs=sGAEpiM... . Onneksi tutkin hieman tarkemmin minkälainen pelti on kyseessä ja huomasin, että se onkin tarkoitettu verkkokorteille. No, minulla on vanhoja 10/100-megaisia verkkokortteja ja 3comin 595:ssa on reiät juuri oikeassa kohdassa ja niitä löysin heti kaksi kappaletta. Ainoa ongelma oli, että se kieleke, johon ruuvi kiinnitetään oli noin millin verran liian lyhyt, mutta se sai taivuttamalla pidemmäksi. Leatherman vyöllä on käytännöllisen nörtin eräs tuntomerkki.

Jos olet jatkanut lukemista tänne asti, tiedät varmaan jo miten tärkeää kunnollinen jäähdytys ja riittävän iso virtalähde ovat, joten ei niistä enempää.

ZFS:n suorituskyvyn säätö

12. 2011

ZFS:n suorituskykyä voi säätää ja parantaa monin tavoin. Tänään esittelen niitä ja niistä löytyvää dokumentaatiota, mutta en esitä vielä mittaustuloksia.

Yleensä ZFS:n säätämisen sanotaan olevan vahingollista, mutta nyt siltä vaaditaan vain tietyntyyppistä suorituskykyä usean päivän ajan. Kopioinnin tultua valmiiksi, säädöt voidaan palauttaa oletuksiin.

Paras kirjoitus aiheesta, jonka löysin on http://constantin.glez.de/blog/2010/04/ten-ways-easily-improve-oracle-so... . Ensimmäiset ja tärkeimmät kolme ohjetta ovat 1. Lisää keskusmuistia, 2 Lisää keskusmuistia, 3. Lisää keskusmuistia. Levylle kirjoituksen nopeuteen keskusmuistin määrällä on kuitenkin hyvin vähäinen vaikutus. Kirjoituksessa viitataan perl-skriptiin ( http://www.cuddletech.com/arc_summary.pl ), jolla saa koosteen välimuistin tehokkuudesta:

Tärkeimmät arvot ovat "Most Recently Used Ghost" ja "Most Frequently Used Ghost". Ne kertovat kuinka usein välimuistista on etsitty tietoa, joka on jo poistettu muistin vähyyden takia. Yllä olevasta tulostuksesta voidaan päätellä, että nyt ei muistin lisäämisellä olisi parannettu nopeutta käytännössä yhtään.

Toinen työkalu, jolla voi seurata juuri sen hetkistä välimuistin suoriutumista on http://blogs.oracle.com/realneel/entry/zfs_arc_statistics . arc_summary kertoo tilastot viimeisimmän käynnistyskerran jälkeen ja jos siitä on jo kauan aikaa, ne voivat olla melko hyödyttömiä.

Vasta kirjoituksen loppuosasta ( http://constantin.glez.de/blog/2010/04/ten-ways-easily-improve-oracle-so... ) löytyi asetuksia, jotka eivät vaatineet muutoksia laitekokoonpanoon. Komennolla:

Säädetään keskusmuistia käyttävää ensisijaista välimuistia niin, että se ei tallenna tiedostojen sisältöä lainkaan, vaan metadataa. Jos levyoperaatiot ovat pelkkää kirjoittamista, tämä on järkevää, mutta normaalitilanteessa näin ei kannata tehdä kuin keskusmuistin vähyyden takia. Koska nyt muistista ei ollut pulaa, oli säätö lähinnä varotoimenpide.

Toinen asetus, jolla jo todennäköisesti oli pienehköä vaikutusta oli:

Tämä asetus pyrkii ryhmittämään useampien tiedostojen kirjaamista lokiin, jotta ne yhdessä käsiteltäisiin nopeammin. Toisella arvolla, "latency" yksittäinen tiedosto käsitellään mahdollisimman nopeasti, mutta keskimääräinen nopeus kärsii.

Lopuksi vielä yksi hieman hankalampi kirjoitusnopeutta lisäävä muutos. http://constantin.glez.de/blog/2010/04/ten-ways-easily-improve-oracle-so... kertoo vain osan tarinasta. ZIL eli Zfs Intention Log voidaan ottaa myös kokonaan pois käytöstä. Se vaatii kuitenkin uudelleenkäynnistystä eikä se muutenkaan ole suositeltavaa. Se on kuin ottaisi journaloinnin pois käytöstä. Ihan näin rajuun operaatioon en ollut valmis. Yksi mahdollisuus olisi ollut käyttää uutta SSD-levyä, jonka olin tilannut toissijaiseksi lukuvälimuistiksi ja joka oli jo saapunut. Se ei olisi kuitenkaan voinut olla pysyvä ratkaisu, koska pooliin lisättäessä sekä loki että välimuistilaitteiden pitää olla koko levy, niitä ei voi osioida tai muuten jakaa. Helppo ratkaisu oli käyttää USB-muistitikkua. Minulla sattui olemaan USB 3.0 -liitäntäinen sellainen ja vaikka OpenSolaris-koneessa ei ole USB 3 -portteja, on muistitikku ainakin hieman tavanomaista nopeampi. Suorituskyvyn kannalta kuitenkin tärkeintä on IO-operaatioiden nopeus, IOPS (IO Operations Per second), ei siirtonopeus ja se flash-laitteissa on hyvä.

OpenSolaris tukee hieman huonosti USB-muistitikkuja. Jos sellaisen kytkee Linux-koneessa, käynnistyy automatiikka, joka näyttää uuden laitteen kuvakkeen työpöydällä tai ehkä avaa sen, sen mukaan miten järjestelmä on konfiguroitu. Linuxissa automatiikan taustalla on udev-järjestelmä, joka luo uusille laitteille automaattisesti sopivat laitetiedostot ja loppu riippuu asetuksista. Sen jälkeen, kun USB-tikku on paikalla, sen tiedot näkee komennolla rmformat:

Jos sen haluaa liittää, on komento (laitetiedosto poimittiin edellisestä listauksesta):

Liitoskohta syntyy automaattisesti ja tikun sisältöä voi listata:

Jonka jälkeen liitos poistetaan komennolla:

ZFS:n loki tarvitsee kokonaisen laitteen, joten yllä olevaa liittämistä ei pitäisi tarvita, mutta jostain syystä tikkua ei voinut heti suoraan ottaa lokilaitteeksi komennolla:

Mitään dramaattista kopioinnin nopeutumista en havainnut, mutta nopeutumista kuitenkin. Täytyy vielä mitata tuo myöhemmin.

Deduplikoinnin evaluontia

Ajatus on, että tämä olisi jonkinlainen päiväkirja, mutta keskittyisi vain yhteen aiheeseen. Täydennän kirjoitusta, kun uutta asiaa tulee ja laitan uuden tekstin alkuun päiväyksen. Todennäköisesti jotain kirjoituksista päätyy seuraavaan Linux-kirjaani, mutta ei samassa muodossa. Yritän kertoa välillä sen verran taustaa, että muutkin voivat tätä seurata, jos tekninen tietämys riittää.

Deduplikoinnin taustaa

ZFS:n deduplikointi tapahtuu blokkitasolla. Tiedostojen nimillä ei esimerkiksi ole mitään vaikutusta. Vaihtoehtoinen tapa on tiedostotaso, jolloin tiedoston on oltava kokonaisuudessaan samanlainen. ZFS:n Deduplikointi tehdään on-line. Vaihtoehtoinen tapa on off-line, joka tarkoittaa, että deduplikointi tehdään joko ajastetusti öisin tai viikonloppuisin tai sitä tehdään aina tarvittaessa, kun järjestelmää ei kuormiteta liikaa.

Myös Linuxissa voidaan hyödyntää deduplikointia millä tahansa tiedostojärjestelmällä, joka tukee kovia linkkejä. Siihen on olemassa jo valmis ohjelma, nimeltä hardlink:

hardlink:in mainetta on pilanneet aikaisemmat viritelmät, jotka eivät ole tarkistaneet, että tiedostojen sisältö on sama. Muistelen erään sellaisen olleen perl-skripti. Jelinekin versio vaikuttaa hyvältä, mutta en kokeile sitä vielä.

Evaluointiympäristön esittelyä

RAID-6 pakka, jossa on 11 fyysistä 2 Tt levyä yhden ollessa varalla. Käyttöön jää 8:n levyn kapasiteetti, joka kymmenjärjestelmän teroina on 16 eli juuri hieman alle ext4:n ylärajan.

OpenSolaris SVN 134 -koneessa on lähes identtinen kokoonpano.

Tiedostotasoinen deduplikointi off-linenä Linuxissa ext4-tiedostojärjestelmällä

Haluan saada ensiksi hieman lukuja siitä, miten paljon deduplikointi voisi vapauttaa levytilaa. Haluan myös kontrolloida, miten statistiikkaa generoidaan enkä sen takia käytä hardlink-ohjelmaa. Ensimmäinen vaihe on kerätä md5-summat:

Tässä on pieni ongelma. Jos oletetaan, että levyä käsitellään nopeudella 100 Mt/s, menee komennon suorittamiseen 22 tuntia aikaa. Onneksi olin keväällä tehnyt samanlaisen tiedoston. Tiedostojärjestelmä on sen jälkeen muuttunut melko vähän, joten vanhasta tilanteestakin saadaan melko käyttökelpoisia lukuja. Kun uusi tiedosto valmistuu, sille voidaan tehdä samat operaatiot kuin nyt harjoitellessa.

Tiedoston koko ja sorttausaika ovat sen takia mielenkiintoisia, että ne antavat viitteitä siitä, miten paljon deduplikointi vaatii resursseja. Tässä tiedostossa on tiedostojen md5-summat, ei blokkien. Blokkien md5-summien kokonaiskoko voidaan laskea, mikään työkalu OpenSolariksessa ei tietääkseni sitä kerro. ZFS:n tarkistussumma on 256-bittinen eli 32-tavuinen. Blokkikoko vaihtelee, mutta käytämme maksimia, joka on 128 kt.

Tuo on tietysti minimi, ja vain käytetylle levylle. http://en.wikipedia.org/wiki/ZFS#Deduplication sanookin:

Tuo tarkoittaa kaupassa käyntiä. OpenSolaris-koneessani on vain 4 Gt fyysistä muistia. Corsair SSD Drive 60GB ForceGT SATA III 6Gb/s 555MB/s Read 495MB/s Write pitäisi riittää.

Melkein miljoona samanlaista tiedostoa, mutta kun katsotaan rivejä tarkemmin, eivät ne kaikki olekaan tiedostorivejä.

Tämä komento on hidas. Awk:ta käytettiin, jotta jokaiselle riville saadaan lainausmerkit, jolloin tiedostonimissä voi olla väliluontejä ja muuta rivoa. Tiedostoon mirrors.md5sum.fs tulostuu sen käyttämä levytila ja tiedostonimi. Seuraavaksi voimme laskea koot yhteen jo käsitellyistä riveistä:

Hieman yli puolet käsitelty. Olisiko joku 1,2 Tt mahdollisuus säästää. On se aika paljon 8 terasta. Tänään ei enää enempää voi tehdä..

16. 12. 2011

Kone sai valmiiksi tiedostojen koon laskemisen. Ei ollutkaan niin paljon varaa säästää:

Olin yöllä vielä huomannut, että uusien md5-summien laskeminen ei ollutkaan ihan järkevästi toteutettu. Tapoin vanhan ja uusi etsii vain tiedostoja, niin ei tule herjaa hakemistoista tai rikkinäisistä soft linkeistä, alla uusi:

Käynnistin tuon 01:31 ja nyt

Melkein päässälasku, reilu mega tunnissa ja vajaa 150 pitäisi vielä tulla, noin 6 päivää jäljellä. Sitä SSD-levyäkään ei ollut hyllyssä vaan maahantuojan varastossa. Ei taida tapahtua vähään aikaan mitään..

Tarkistetaan kuitenkin, mistä hitaus johtuu, atop auttaa

Yksi ydin on selvästi rasitetuin eli se ajaa md5sum:ia ja levyt ovat korkeintaan puolityöllistettyjä. Ei se kovin suuri homma olisi tehdä ensin tiedostolistaus find:lla ja sitten skripti, joka varaa käsiteltävän tiedoston semafori- eli lukitustiedostolla. Skriptin voisi hyvin käynnistää kolmeen  kertaan. Jää iltaan, pitää käydä lääkärissä ja muuta triviaa..

16. 12. 2011 iltapäivä

Olikin odotettua nopeampaa se md5-summien laskeminen. Suurin osa tiedostoista lukumääräisesti on varmaan mp3:ia. Yli tuhat albumia ja vielä toiseen kertaan piukemmin pakattuna kannettavaa mp3-soitinta varten. Tilaa vievät kuitenkin eniten TV-tallenteet ja kopioidut DVD-levyt, yhteensä melkein 7 teraa.

No, joka tapauksessa syntyi

Ja sille samat operaation kuin keväällä tehdylle tiedostolle. Ensin kuitenkin selitystä, että miten se noin nopeasti meni:

Periaatteessa voisi olla nopeampikin, mutta kun sen SAS-kortin joutui korvaamaan, piti tilalle laittaa yksi PCI-korttikin. Emolla on jo hieman ikää eikä montaa pitkää PCI-e slottia ja useampiporttiset SATA-adapterit hävyttömän kalliita. SAS-adapteriin voi laittaa myös SATA-levyjä, mutta se ei Linuxissa oikein toimi. Jatkossa OpenSolariksessa rääkätään sen verran, että nähdään toimiiko siellä. (kauhea määrä selittelyä..)

Sitten vaan copy pastea, mutta tiedostonimissä pientä eroa:

Vilkaistaan OpenSolaris-konetta ja sen levyjä:

Systeemilevy ja 9 kpl 2-teraisia ja niille on luotu:

Kolminkertainen pariteetti. Muistaakseni hidasti aika paljon, joten nopeustesteissä ei kannata odottaa liikoja.

/tank on varmaan oletuksilla eikä esim. deduplikointia ole käytössä, mutta tarkistetaan:

Joo, mennään sinne ja testataan kirjoitus- ja lukunopeudet:

Kirjoitusnopeuden keskiarvo on 126 Mt/s.

Lukunopeuden keskiarvo on 214 Mt/s. Nyt kun nopeudet on testattu, voidaan vaihtaa adapteri. Kun kone on käynnistetty uudelleen, on hyvä tarkistaa, miten OpenSolaris näkee levyt:

Nyt näkee selvemmin, että 3 kpl isoista levyistä on emolevyn liitännöissä ja SAS2-adapterissa vain 6 kpl, eli kaksi mahtuisi vielä. Tämä sopii hyvin muistaen SSD-levyvalintani, joka oli SATA-3-levy. SAS2:n ja SATA-3:n nopeudet ovat samat eli SSD-levyn nopeus saadaan täysin käyttöön.

Sitten vain samat testit:

Aika hyvä. Lukunopeuteen n. 20 % lisää ja kirjoitusnopeuteen vielä enemmän.

Luvut ovat itse asiassa yllättävän hyviä. Kyse on raidz3:sta ja lisäksi levytilaa on jo käytetty yli 2/3-osaa ja levyn loppuosan nopeus on tyypillisesti vain puolet alkuosan nopeudesta. Näillä vehkeillä voisi saada reilusti yli 500 Mt/s lukunopeutta tyhjällä RAID-0-tyyppisellä levyllä, mutta katsotaan..

18. 12. 2011

root@rk6:~# zpool destroy tank

11 teran hukkaaminen on varsin nopeaa. Nyt voidaan tarkistaa yksittäisten levyjen kirjoitusnopeus:

Emolevyn liitännät hidastelee. Lukunopeus vielä:

Nyt tuli pieni epäilys. Niin lähellä SATA-1:n maksiminopeutta, että voisiko se rajoittaa. Samsungin speksit sanoo: "Data Transfer Rate / Media to/from Buffer(Max.) - 250MB/sec", mutta googlaamalla löytyy, että muutkin ovat saaneet vain 140 Mt/s tason tuloksia. Levyn pyörimisnopeus on vain 5400 RPM - ei pitäisi lämmetä pahasti ja virtapihi.

Hidastavatko emolevylle liitetyt kokonaisuutta? Katsotaas..

Sitten taas sileäksi ja yksi emolle liitetty lisää. Käy muuten sekunneissa nuo kaksi ensimmäistä operaatiota.

Pienoista nopeutumista ehkä. Voi olla, että emonkin kyvyt ovat rajoite. Prosessorina siinä on 2-ytiminen 2,2 GHz Athlon64 4200+. Täysi setti peliin:

Pienoista hidastumista. Melkeinpä veikkaan, että saman tavaran jakaminen useampaan osaan rasittaa sen verran, että emo se on joka on hidaste, Loistavia lukuja silti. Entäs eri raidz-tasot?

Tässä vaiheessa pysähdytään sen takia, että tarkistetaan, palaako levyjen valo. Ei pala. Linuxissa mdadm:n kanssa palaisi. Melkein vuorokauden. Ei kun eteenpäin.

Pariteetin laskeminen ja tarkistaminen tietysti hidastaa. Epämiellyttävän paljon. Entä seuraava taso?

Kun pariteetti on kerran laskettu, ei sen tallennus toiseen kertaan enää paljon maksa. Entä kolmas kerta?

Nyt onkin sitten mietintämyssyn paikka. Mikä raidz-taso halutaan? Se on selvää, että pariteetti pitää olla. Lukunopeus kaikissa on lähes sama. Ero on alle 10 %. Kirjoitusnopeudella ei ole yhtä paljon väliä. Tämä johtuu siitä, että kirjoitettava data tulee pääasiassa Ethernetin kautta ja vaikka miten olen yrittänyt, ei Ethernet bondingilla ole saanut kahden koneen välistä yhteyttä nopeammaksi.

Yksi tärkeä tekijä, joka tällä kertaa vaikuttaa sopivaan raidz-tasoon on se, kuinka paljon tallennustilaa tarvitaan ja kuinka monta levyä koteloon saa mahtumaan. Oikeastaan minimivaatimus on, että tallennustilaa pitää olla yhtä paljon kuin aiemmin mainitussa Linux-koneessa eli 16 Tt ja koska levyjä on niin paljon alin taso on raidz2. Se tarkoittaa vähintään yhtä lisälevyä. Kotelossa on kuitenkin käytetty kaikki normaalit levyjen ripustuspaikat.

DVD-aseman voisi poistaa ja se olisi kaikkein helpoin ratkaisu. Toinen mahdollisuus olisi siirtää DVD-asema ylimmäksi 5 1/2-tuumaisten osastossa ja kun siellä olevat kiintolevyt ovat jo nytkin vain toisessa reunassa kiinni, niin niiden sivuun mahtuisi yksi pystyyn. Se voisi kuitenkin vaatia askartelua ja jos sille linjalle lähdetään, minulla olisi pari vapaata täystorniakin..

DVD-asema pois ja jos sellaista tarvitaan, USB-liitäntäinen Blu-Ray-asema kiinni.

SSD-levy on 2,5-tuumainen eli läppärin kiintolevyn kokoinen. Se mahtuu vaikka minne ja kuluttaa 0,6 - 2,5 wattia eli ei lämpene. Eikä myöskään tärise, joten kiinnityksen ei tarvitse olla tukeva, kätevä riittää.

Tarvitaan siis yksi 2 Tt kokoinen levy lisää ja se löytyy sieltä Linux-koneelta, jossa saattuu olemaan yksi ylimääräinen (spare). Katsotaas:

Spare on sdi, mikä levy?

Juuri sopiva. Siellä on useampi tuota mallia, mikä niistä, ei viitsi kaikkia ottaa irti, että näkisi sarjanumeron, idea!

Sdi on selvästi lämpimin Samsung. Koittamaan niitä sormella ja se löytyi :)
Seuraavaksi tutkimaan voisiko sen ottaa irti konetta sulkematta. Linuxissa on jonkinlainen hot-plug tuki..

19. 12. 2011

Vaikka SSD-levy ei vielä ole saapunut, voin kopioida tiedostot rsync:llä ja simuloida zdb:n avulla, miten paljon tilaa voisi säästää deduplikoinnilla ja pakkauksella. Niitä ei ehkä kannatakaan ottaa käyttöön, jos säästö jää pieneksi. Deduplikoinnista Oraclen dokumentaatio sanoo, että se kannattaa vasta, jos suhdeluku tiedostojen koko jaettuna tarvittavalla tiedostojen koolla on yli 2. Lisäksi on mahdollista käyttää tiedostotason deduplikointia, jolla jo tiedämme saatavan noin 10 % säästön sillä hakemistopuulla, joka on tarkoitus kopioida ZFS:lle. Käynnistetään siis kopionti:

Se ei kuitenkaan tule valmiiksi tänään. 8 Tt ei siirry gigabitin Ethernetillä hetkessä. Parhaassa tapauksessakin aikaa menee reilu 22 tuntia.

Palataan edellä mainittuun viestiketjuun zfs-discuss-postituslistalla. Myös tiedostojen poistaminen vaikuttaa olevan hidasta ZFS:llä. Ei siitä tällä kertaa enempää kuin hieno ja erikoinen skripti, joka käynnistää jokaiselle poistettavalle tiedostolle oman rm-prosessin. Mitä kaikkea shell-skripteillä voikaan tehdä!

Tuo tiedostojen poiston hitaus voisi selittää keväiset ongelmani snapshottien poistossa. OpenSolaris-kone oli kesän kylmänä ja vasta äskettäin kokeilin onnistuuko nyt snapshottien poisto. Ei mitään ongelmaa.

21. 12. 2011

Tiedostojen kopionti on edelleen meneillään, 3/4 valmiina. Huomenna hän tulee..

Tuota edellistä lausetta kirjoittaessa minulla oli jo Godot mielessä, mutta sitten tuntemus vahvistui. Laskin, miten nopeasti ZFS-levy täyttyy ja sain tulokseksi vajaa 7 Mt/s. Linux-koneen levyvalo välkähteli hyvin harvoin ja lyhyesti. OpenSolaris-koneessa se taas oli melkein koko ajan päällä. Miten kauan loput reilu pari teraa veisivät? 69 tuntia. (sensuroitu) Nyt säätämään, mutta ensin dokumentointia esiin, löytyi http://www.solarisinternals.com/wiki/index.php/ZFS_Evil_Tuning_Guide#Lim... . Tosin en halua pienentää sitä, vaan suurentaa. Suurennan sitä ensin varovaisesti:

Melkein kaikki muisti on tarjolla. Nopeus kyllä kasvoi, noin 9 Mt/s. Ei silti hyvä. Tutkin, mikä voisi olla pielessä. Mitään apua ei löydy.

Sitten tapahtuu jotain ikävää, X kaatuu. Myös se Konsolen kieleke, jossa käynnistin kopioinnin, on mennyttä. Samasta syystä jouduin yllä suodattamaan historiaa. KDE käyntiin taas ja myös rsync, joka hoitaa kopioinnin. Lisään kuitenkin --progress-vivun, jotta voin helposti seurata siirtonopeutta. Se aloittaa aika tasaiseen 112 Mt/s tahtiin, mutta vajaan neljän gigan kokoisen tiedoston loppupäässä hidastelee, välimuistit täyttyivät. Keskiarvo silti 78.65MB/s. Seuraava 42.63MB/s. Sitten taas nopeammin. Pidemmän ajan keskiarvo näyttää olevan yli 50 Mt/s. Huh!

Mitä ihmettä oikein tapahtui? Välimuisti fragmentoitui tai jotain vastaavaa tiedostojärjestelmän puolella. Parempaa arvausta en keksi. Opetus taitaa kuitenkin olla: älä kopioi yli neljää teraa kerralla, pidä tauko ;)

24. 12. 2011

Kopionti tuli vihdoin eilen valmiiksi. 8 teraa, yli 1,6 miljoonaa tiedostoa ja 165 tuhatta hakemistoa. Aikaa kului noin 5 vrk. Kopiointi ei kuitenkaan ollut sujunut virheittä. Tiedostojen omistajuudet olivat pielessä. Hakemistopuussa on esimerkiksi muutaman Linux-koneen juuriosioiden varmistuskopiot ja niillä tietysti useita pääkäyttäjän omistamia tiedostoja. OpenSolariksessa ei näytä olevan helppoa tapaa jakaa NFS:n avulla täysin oikeuksin, joten helpoin tapa on tehdä kopioinnin viimeistely toisinpäin, Linux jakamassa ja OpenSolaris-koneella käynnistetään kopiointi. Linuxissa jaolle annetaan täydet oikeudet exports-tiedoston kautta:

OpenSolariksessa on NFS-versio 4 ja ja se on mount-komennon oletus. Linuxissa taas version 4 toteutus on vielä vajaa, joten liitoskomentoon tarvitaan lisämääre:

Tämän jälkeen varmistetaan, että kopioitu hakemistopuu on täysin identtinen:

Edellisen komennon ajo ei enää vienyt kovin pitkää aikaa, ehkä pari tuntia. Pian saisimme vastauksen deduplikoinnin tilansäästöstä:

Keskusmuistia on 4 Gt ja levyltä on lohkaistu parin gigan siivu swappia. Swappia siis lisää. Helpoiten sitä saa ottamalla USB-tikun pois lokikäytöstä ja antamalla se swapiksi. zdb:stä käynnistetään varmuuden vuoksi täyden polun kanssa 64-bittinen versio:

Nyt zdb on ollut jo noin vuorokauden työssään, top:in mukaan se on syönyt muistia 9452 Mt ja kone on täysin hyytynyt. Se vastaa pingiin, mutta top:sta ei pääse ulos q-näppäimellä eikä zdb kuole Ctrl-C:llä. Yritin lisätä ennen hyytymistä sivutustiedoston, mutta se ei onnistunut. Alla komennot ja lopputulos:

On siis aika sammuttaa kone ja lisätä levyjä. Linux-koneessa hot-unplug on yksinkertainen toimenpide:

Lyhyen tähtäimen suunnitelma on käyttää SDD-levy kokonaisuudessaan väliaikaisesti swappina zdb:n ajon ajan. Tulos saadaan ehkä jo huomenna.

25. 12. 2011

Resilvering

Uusien levyjen käyttöönotto ei sujunut ilman kommelluksia OpenSolariksessa ja niihin kului aikaa. Eräs niistä on kuitenkin kertomisen arvoinen. Aikaisemmin SAS2-korttiin oli liitetty vain 6 levyä ja halusin, että kaikki sen 8 porttia otettaisiin käyttöön. Linuxissa tämä olisi onnistunut ongelmitta, mutta OpenSolaris ei huolinut toiseen adapteriin siirrettyä levyä. Se taas on mysteeri, että miksi aiemmin SAS-kortin vaihto SAS2-korttiin ei aiheuttanut samanlaista ongelmaa. Tämä ei oikeastaan ollut vielä se mielenkiintoinen asia vaan ZFS:n "resilvering", prosessi, jossa vanha jo poistettu levy korvataan uudella. Sen käynnisti komento:

Tilanne levypoolissa näytti 10 tunnin kuluttua seuraavalta:

Et ehkä huomannut sitä, että kahden teran levystä puolet oli käsitelty, mutta jäljellä oli enää viidennes. Selitys ristiriidalle on se, että loput 30 % on käyttämätöntä tilaa ja sille ei tarvitse tehdä mitään. Linuxin RAID ei ymmärrä mitään tiedostojärjestelmästä, joten se käsittelee vastaavassa tilanteessa aina koko levyn. Uuden pariteetillisen RAID-pakankin se aluksi käsittelee alusta loppuun laskien pariteetin. ZFS-poolia luotaessa se on tyhjä, joten sitä ei tarvitse käsitellä. Alla vielä kokonaisaika:

Kuvat

Kaikki kuvat on otettu Linux-koneella. OpenSolaris-koneella on oma näyttö, näppäimistö ja hiiri, jotka se jakaa KVM-laitteen kautta kolmen muun koneen kanssa. En kuitenkaan viitsi siirtyä näyttöjen väliä, joten käytän ssh:ta. Kaksi ensimmäistä kuvaa vaativat kuitenkin OpenSolariksen Device Driver Utility -ohjelman nimen selville ottoa. Kirjauduin sisään tunnuksella rk OpenSolaris-koneella, Linux-koneella ssh-sessiossa komento "ps aux | grep rk", takaisin OpenSolaris-koneelle, ohjelma käyntiin, Linux-koneelle, sama ps-komento ja etsitään listaukseen ilmestynyt uusi ohjelma. Tämän jälkeen Linux-koneella ikkunoidussa komentotulkissa:

Ja Linuxin työpöydälle ilmestyy OpenSolaris-koneessa käynnistetyn ohjelma ikkuna. Kuvakaappaus yhdestä ikkunasta komennolla "import -frame ddd1.jpg" ja klikataan haluttua ikkunaa.

OpenSolariksen näkemys laitteistosta

Tarkempi näkymä SAS-2-adapterin levyistä

top näyttää prosessit, muistin käytön ja prosessorin kuormituksen. Tämä Konsolen kieleke on ssh-sessio OpenSolaris-koneeseen.

SATA-3 SSD-levy

SSD-levyt pitäisi osioida niin, että levyn sylinteri osuu 4 kilotavun sivun rajalle. Se onnistuu tietyillä levyn geometrioilla. OpenSolariksessa tämä ei näytä olevan ongelma, sillä format kertoo SSD-levyn geometrian olevan juuri sopivan:

Linuxissa ei aina ole näin onnellisesti. Aihetta tarkemmin käsittelevä artikkeli löytyy täältä: http://www.linux-mag.com/id/8397/

No, testataan levyä hieman

Ei niin hyvä kuin luvattiin, mutta eteenpäin, otetaan swapiksi

Säädetään ZFS:n välimuistin käyttöä pienemmäksi, kaikki muisti on nyt kallisarvoista.

Aikaisemmalla zdb:n ajokerralla huomasin, että se näyttää ensin käyvän tiedostojärjestelmän läpi lukien tarvitsemansa metadatan. Sen käyttämä muistimäärä nousee lukuvaiheen aikana hieman yli 9 gigaan. Sen jälkeen se alkaa analysoimaan tietoja eikä enää, ainakaan levyvalojen mukaan. lue levyä. Edellisillä kerroilla muisti on loppunut kesken, joten sitäkään ei tiedetä, miten pitkään analysointi olisi jatkunut. Nyt muistia kuitenkin löytyy varmasti tarpeeksi. Oheisessa kuvassa top ilmoittaa swapin kooksi peräti 58 Gt ja nyt se on aika mukavan vikkelällä levyllä.

1. 1. 2012 – Tulokset

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:

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

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:

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:

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 <juuri>[/väli-dataset]/<uusi_dataset>" ja esimerkiksi deduplikoinnin käyttöä ohjataan komennolla "zfs set dedup=on|off <dataset>".

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.

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.

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:

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

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

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-oikeudet NFS-jakoihin

NFS-jaot määritellään komennolla "zfs set sharenfs=on|off <dataset>". 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:

Tuo ei kuitenkaan saa jakoa pysyväksi. Aikaisemmin jaettavat polut määriteltiin suoraan tiedostoon /etc/dfs/dfstab, mutta nykyisin sitä pitäisi välttää ja käyttää sen sijaan sharemgr-komentoa. Se taas ei ole aivan suoraviivaista. Ensin pitää määritellä ryhmä, johon jaettava polku tai polut lisätään ja vasta sitten ryhmän ominaisuuksia voidaan muuttaa. Kolmella komennolla se kuitenkin onnistuu:

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

Se ei valmistu ihan heti..

Sillä aikaa jaon voi määritellä Linux-koneen /etc/fstab-tiedostoon, jotta optiota ei tarvitse muistella. Seuraava rivi hoitaa homman:

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.

ZFS - Stressitestausta ja flashin vaikutus

ZFS:ää voi nopeuttaa lisäämällä SSD-levyn välimuistilaitteeksi. Toinen nopeutuskeino on lisätä flash-muistia lokilaitteeksi. Vaikka kymmenen kiintolevyn raidz2-järjestelmä on erittäin nopea suurten tiedostojen käsittelyssä, teoriassa jopa 8 kertaa nopeampi kuin yksi levy, on pienten tiedostojen käsittelyn nopeus teoriassa sama kuin yhden levyn. Sen takia pienikin määrä kiintolevyyn verrattuna hakunopeudeltaan ylivoimaista flash-muistia kriittisessä paikassa voi nopeuttaa koko järjestelmää selvästi. Kumpi sitten on tärkeämpi, välimuisti vai lokilaite? Entä kuinka suuri sen pitäisi olla? Lokilaitteen ei tarvitse olla suuri, mutta välimuistilaitteen koolla on jo väliä.

Testauksen tavoitteet

Evaluointivaiheessa kopioitiin 8 Tt tiedostoja Linux-koneelta ja ensimmäisellä kerralla kopiointi hidastui matkan varrella huomattavasti. Tiedostoja oli noin 1,6 miljoonaa, joten varsin helposti heräsi epäilys, että tiedostojen määrällä olisi ollut vaikutusta hidastumiseen. Kopiointi toistettiin, mutta silloin ZFS:llä oli käytössä erilliset välimuisti- ja lokilaitteet eikä hidastumista enää esiintynyt. Nämä olivat havaintoja, joiden taustalla ei ole mittaustuloksia eli lähes MUTUa. Jotta asia selviäisi, paras testi olisi luoda erittäin suuri määrä tiedostoja ja mieluummin pieniä, jotta testin ajoaika olisi mahdollisimman lyhyt.

Toinen tavoite oli selvittää flash-muistin vaikutus nopeutuksessa. Usean levyn RAID-pakan kirjoitus- ja lukunopeudet ovat erinomaiset, mutta hakuaika tai IOPS (Input/output Operations Per Second) on yhtä huono kuin yhden levyn. Flash-muistin siirtonopeudet eivät yleensä häikäise, mutta IOPS-luvut ovat aivan eri tasolla. Täytyy kuitenkin muistaa, että kiintolevyjen apuna on aina keskusmuistipohjainen välimuisti, joka on vielä vikkelämpää kuin flash-muisti, joten flashillä ei välttämättä kovin suuria parannuksia saavuteta. Myös tässä paras testi on mitata pienten tiedostojen käsittelyn nopeutta.

Kolmas tavoite oli selvittää, voisiko melko arvokkaan SSD-levyn korvata halvemmalla vaihtoehdolla. Aluksi tämä tavoite oli lähinnä etäinen toive, mutta sen järkevyys nousi esille varsin pian.

Käytettyjen laitteiden luku- ja kirjoitusnopeudet on myös tietysti hyvä testata, vaikka niillä ei tavoitteiden kannalta olisikaan merkitystä, niiden testaus on vain niin nopeaa ja helppoa ja lisäksi mittaustulokset auttavat hahmottamaan kokonaiskuvaa.

Testimenetelmät

Edellä mainittu kopioinnin hidastuminen johtui mitä ilmeisimmin metadatan käsittelystä. Voisiko syy olla hakemistopuun rakenteessa? Erittäin syvä hakemistopuu tai erittäin paljon tiedostoja yhdessä hakemistossa?

Hakemistopuun ja tiedostojen luominen olisi helppo toteuttaa skriptin avulla, mutta tarve on niin ilmeinen, että siihen löytyi valmis skripti: https://computing.llnl.gov/code/sio/tarballs/fdtree-1.0.2.tar.gz . En löytänyt sitä suoraan vaan Linux Magazineen ( http://www.linux-mag.com ) kirjoittaneen Jeffrey B. Laytonin ( http://www.linux-mag.com/author/311/ ) artikkelin ( http://www.linux-mag.com/id/7497/ ) kautta.

Linux Magazinen julkaisu on valitettavasti lopetettu kesällä 2011, mutta vanhat artikkelit ovat edelleen luettavissa ja Jeffrey B. Layton jatkaa kirjoittamista enterprisestorageforum:ssa ( http://www.enterprisestorageforum.com/author/Jeffrey-Layton-2040.htm ).

Hakuammuntaa

Yritin siis etsiä hakemistorakennetta ja tiedostomäärää, jolla hidastuminen ilmenisi. Erilaisten hakemistopuurakenteiden testitulokset vaihtelivat, mutta IOPS pysyi samana (tästä lisää myöhemmin). Koska samalla oli tarkoitus testata myös flash-muistin vaikutusta eri tavoin, testiajon pituudella oli käytännön rajoitus, aikaa ei saisi kulua tuhottoman paljon. Pisin testiajo, johon päädyin oli 29 miljoonan tiedoston luonti ja se vei yli kaksi vuorokautta aikaa. Fdtree ei anna välituloksia ja sen takia testin aikana mahdollisesti tapahtuva hidastuminen jäisi huomaamatta. Tämän puutteen poistamiseksi tein pienen skriptin:

Skripti tulostaa puolen tunnin välein testattavan tiedostojärjestelmän vapaan tilan sekä kellonajan ja tekee niin sadan tunnin ajan. Jos skriptin tulosteen ohjaa komennolle:

awk '{if (PREV) print ($1-PREV)/4/1800 ; PREV=$1}'

tulostuu kuinka monta tiedostoa on luotu tai kuinka monta kertaa hakemistojen metadataa on kasvatettu keskimäärin sekunnin aikana kunakin edeltävänä puolena tuntina.

Hidastumista ei kuitenkaan ilmennyt. Skriptistä oli kuitenkin se hyöty, että se näytti, että vapaa tila väheni melko tarkalleen yhtä nopeasti hakemistopuun rakenteesta huolimatta. Syvässä hakemistopuussa hakemistojen metadataa jouduttiin päivittämään useammin ja sen takia tiedostojen luonti oli hitaampaa. Matala ja leveä hakemistopuu on tavallaan tehokkaampi. Siinä metadatan osuus on pienempi tiedostojen määrään verrattuna.

Testausta hidastumisen etsintä kuitenkin hidasti. Kunkin konfiguraation yksi testiajo kesti tosiaankin yli kaksi vuorokautta. Lisäksi alussa kokeilin erilaisia hakemistopuumalleja enkä heti alussa päätynyt siihen, että 29 miljoonaa tiedostoa on riittävän paljon, vaan kokeilin ensin vaatimattomammilla määrillä. Siinä sitten vierähti viikko jos toinenkin..

Näiden testien tulokset ovat ensimmäisessä kuvassa. Testin käynnistänyt komento oli "fdtree -d 90 -f 40 -s 1 -l 3" ja se tulosti käynnistäessään:

Kuvaajaa tulkittaessa on huomattava, että tiedostojen luontiin käytettiin selvästi eniten aikaa. Se on siis kaikkein tärkein tulos. Hakemistoja luodaan harvoin niin suuria määriä kerralla, että nopeudella olisi suurta merkitystä. Käytännössä hakemiston luonti oli yhtä nopeaa kuin tiedoston luonti, mutta Linuxin ext4:llä se oli hieman nopeampaa. Ext4:n tuloksia ei oikeastaan olisi pitänyt laittaa samaan kuvaajaan, koska sen testiajot tehtiin toisessa, selvästi nopeammassa koneessa. Kiintolevyt ja niiden määrä olivat kuitenkin lähes identtiset ja hyvin suurella todennäköisyydellä Linux-koneen nopeampi keskusmuisti oli suurin selittäjä paremmille tuloksille tiedostoja ja hakemistoja luotaessa. Niiden poistossa ext4 oli selvästi hitaampi, joten ainakin siltä osin testi todisti, että ZFS on parempi. Tiedostojen ja hakemistojen luomisen osalta en uskalla edes arvailla kumpi tiedostojärjestelmä on parempi.

Flash-muistin vaikutusta testattiin usealla eri tavalla. Tuloksissa huomiota herätti se, että ne ovat lähes identtisiä. Jos flash-muistia käytetään ZFS:n apuna, se nopeuttaa, mutta sillä ei näytä olevan väliä, onko se välimuisti- vai lokilaitteena. Lisäksi 8 gigan kokoinen USB-tikku, vaikkakin nopea sellainen, nopeuttaa yhtä paljon kuin 60 gigan huippunopea SSD-levy. Silläkään ei ollut merkitystä, jos sekä välimuisti- että lokilaitteena oli flash-muistia.

Laitteiden nopeudet

Tallennuslaitteilla on käyttöjärjestelmän kannalta vain kaksi mielenkiintoista ja siis testaamisen arvoista ominaisuutta: siirtonopeus ja hakuaika. Siirtonopeus on hyvin helppo testata ja sen vaikutus on helppo ymmärtää. Hakuaikaa on vaikea testata eikä sen vaikutusta käytäntöön ole helppo ymmärtää. Edellä on yritetty havainnollistaa hakuajan merkitystä. Hakuajan vaikutusta on yritetty kautta aikain minimoida välimuisteilla eri tasoilla ja eri tavoin. Tallennuslaitteen pitkä hakuaika on siis periaatteessa huono asia, mutta käytännössä sen vaikutusta harvoin näkee. Hakuaikaa hieman käytännöllisempi suure on IOPS. Sekään ei ole helposti suoraan mitattava arvo. Jos esimerkiksi luetaan tiedostoa, on metadatan käsittely yksi tai useampi IO-operaatio, johon ei vaikuta pelkästään hakuaika, metadata pitää myös lukea. Kun tiedoston sijainti on löytynyt, pitää sekin lukea. Käytännössä kaikki tiedostojärjestelmässä tehtävät haut ja muut operaation vaativat useita muita operaatioita ja hakuaikojen lisäksi nopeuteen vaikuttaa myös luku- tai kirjoitusnopeus. Kirjoitus- ja lukunopeus sen sijaan ovat hyvinkin tarkkaan samat kuin suuren tiedoston kirjoitus- ja lukunopeus.

Mittaustulokset ovat yllä. Koska tulosten hajonta on hyvin suuri eikä kuvaajassa näy tarkkoja arvoja, ovat tulokset myös alla taulukkona:

     Pelkät kiintolevyt        SSD       USB   Linux, ext4
Kirjoitus           207        198       8,6    316
Luku                283        529      32,5    352

Flash-muistin vaikutus ZFS:n nopeuttajana - toinen testisarja

Yli kahden vuorokauden ajoaika testille on hankala. Jos testattavia vaihtoehtoja on useita, menee ikä ja terveys. Toisaalta testin ajoaika ei saa olla liian lyhytkään, muuten sen luotettavuus ja tarkkuus kärsii. Vaihtoehtoja haarukoidessa muutama minuutti olisi sopiva. Tiedostojärjestelmää testatessa pitää kuitenkin pitää aina mielessä se, että keskusmuistia käyttävä välimuisti sekoittaa helposti testitulokset, joten joko sen vaikutus pitää ohittaa testausjärjestelyiden avulla tai testiajon pituus pitää olla melko pitkä. Päädyin komentoon "fdtree -d 3 -f 16 -s 1 -l 10", jonka ajoaika oli käytetyillä laitteistoyhdistelmillä kahden ja kolmen tunnin välillä. Eräs tärkeä syy valintaan oli se, että sen vaatima tallennustila mahtui USB-tikulle.

Testin käynnistänyt komento  "fdtree -d 3 -f 16 -s 1 -l 10" tulosti käynnistäessään:

Mittaustuloksista huomataan, että USB-tikku ZIL- eli lokilaitteena antoi paremman tuloksen kuin välimuistina ja vain aavistuksen verran huonomman kuin SSD-levy lokilaitteena. Ensimmäisessäkin testisarjassa USB-tikku lokilaitteena oli vain aavistuksen verran heikompi kuin SSD-levy lokilaitteena. Jos flash-muistia halutaan käyttää, on USB-tikku lokilaitteena lähes paras sekä helppo ja halpa valinta. Tässä testisarjassa nousee kuitenkin esille se, että keskusmuistia käyttävä välimuisti riitti ja kiintolevyt ilman flash-muistia olivat yhtä nopeita kuin SSD-levy. Myös Linux-koneessa keskusmuistia käyttävä välimuisti näytti kyntensä ja sen kaikki tulokset ovat selvästi parempia kuin hitaampaa keskusmuistia käyttävän OpenSolaris-koneen. Vaikka flash-muisti ei tässä testisarjassa nopeuttanut, ei se myöskään hidastanut ja parin kympin arvoinen USB-tikku on halpa vakuutus sille, että tiedostojärjestelmä ei hidastu erittäin raskaissa operaatioissa.

Flash on keskusmuistia hitaampaa

Deduplikointi vaatii paljon muistia, mutta SSD-levyllä voi "jatkaa" usein rajallista ja liian pientä keskusmuistia. Flash-muisti ei kuitenkaan ole yhtä nopeaa kuin keskusmuisti, joten deduplikointi hidastaa silti siinä vaiheessa, kun keskusmuistipohjainen välimuisti ei enää riitä. Kuinka paljon se sitten hidastaa? Tämä riippuu tietysti laitteistosta - kuinka nopeaa keskusmuisti on suhteessa SSD-levyyn. Käyttämässäni laitteistossa keskusmuisti on melko hidasta, tyyppiä DDR-400. Kaikki levyt sen sijaan ovat nopeita, käytännössä uusia ja SSD-levy varsinkin on käytännössä niin nopea kuin vain kohtuullisella hinnalla kaupasta saa. Ainoastaan suoraan PCI-e-väylälle liitettävät flash-kortit olisivat selvästi nopeampia. Tuloksissani deduplikointi hidastaa siis vähemmän kuin tasapainoisemmassa laitteistossa.

Testijärjestelyt

Aiemmin käytetty fdtree-skripti kirjoittaa luomiinsa tiedostoihin pelkkiä nollia. Ne deduplikoituvat täydellisesti lukuunottamatta ensimmäistä blokkia tai tiedostoa, jos ne ovat pieniä. Sitä pitää siis muuttaa, jotta testitiedostot eivät deduplikoituisi. Käytännössä tein siitä kuitenkin kopion nimellä fdtree-urand ja muutin dd-käskyn lähteeksi /dev/urandom-pseudolaitteen. Alkuperäinen versio on hyvä verrokki, sillä normaalikäytössä suositusten mukaan ainakin puolet blokeista pitäisi olla deduplikoituvia. Alla muutettu rivi:

dd if=/dev/urandom bs=4096 count=$fsize of=$file_name > /dev/null 2>&1

Ideaalitilanteessa deduplikoituvuus tiedettäisiin etukäteen ja testiohjelma tuottaisi juuri sen verran deduplikoituvaa materiaalia. Varsin työläs tapa olisi tehdä skriptivariaatioita tai lisäparametri deduplikoituvuusasteille ja ajaa testit esimerkiksi asteille 2, 3, 4 jne. Ääripäät antavat kuitenkin jo jonkinlaista tuntumaa.

Toinen skriptimuutos liittyy siihen, että tein erillisen datasetin (käytännössä uusi alihakemistopuu, jonka ominaisuuksia, kuten deduplikointia, voidaan muuttaa) testausta varten. Muutin myös raportointiväliä dftrack-skriptissä:

#!/bin/sh
for i in `seq 1200`
do
   sleep 5m
   df | awk '/tank\/dedup/{printf $3" "}'
   date
done


Uusi dataset luotiin ja asetusta muutettiin käskyillä:

Edellä esitelty dftrack-skripti käynnistettiin komennolla:

Sen jälkeen itse testiohjelma:

Tiedostoja on siis hieman yli 10 miljoonaa.

Alkuperäinen fdtree käynnistettiin samoilla parametreillä.

Tulokset ja niiden tulkinta

Ensin fdtreen tulokset taulukkona.

Hakemistojen luonti ja poisto on yhtä nopeaa, joten ne ovat testin kannalta turhia tuloksia. Lisäksi kokonaisaikaan niillä on mitätön merkitys. Tiedostojen käsittelyssä ero on sen sijaan suuri. Tiedostojen poisto on melko nopeaa, mutta siinä suhteellinen ero on hyvin suuri. Kokonaisajan kannalta sen merkitys on kuitenkin melko vähäinen. Tiedostojen luonnin nopeus on koko testin kannalta tärkein, ja siitä on erillinen graafi. Kun vertailee tiedostojen luonnin nopeuksien suhdetta ja kokonaisaikojen suhdetta, pitäisi huomata, että se on hyvin tarkalleen sama. Tiedostojen luontinopeus dominoi siis koko testiä.

Graafissa ei ole vaaka-akselilla asteikkoa, koska se ei olisi tarkka. Se on kuitenkin aika-akseli ja kuvaajien pituudesta voi päätellä testiajojen viemän ajan. Punaisen kuvaajan alussa on yksi alhainen mittapiste, joka johtuu mainitusta epätarkkuudesta ja se olisi pitänyt oikeastaan poistaa virheellisenä. Samaa voisi uumoilla sinisenkin alkuosan kuopasta, mutta se todennäköisimmin on samaa vaihtelua, joka näkyy koko kuvaajassa. Jos mittausväli olisi ollut suurempi kuin 5 minuuttia, ei vastaavaa "sahausta" olisi näkyvissä.

Graafissa merkittäviä havaintoja on se, että deduplikoituvan materiaalin kirjoittaminen on aina hieman nopeampaa kuin deduplikoitumattoman. Jos deduplikoinnin käyttämä metadata on ensisijaisessa välimuistissa, on ero kuitenkin melko pieni. Toisin olisi, jos tiedostojen koko olisi suurempi. Silloin tiedoston vaatiman uuden metadatan kirjoittaminen olisi pienempi operaatio verrattuna itse tiedoston kirjoittamiseen.

Deduplikoitumattomien tiedostojen kuvaajassa tapahtuu melko jyrkkä lasku eli hidastuminen. Se, missä vaiheessa hidastuminen tapahtuu, riippuu siitä, miten paljon välimuistia on jo aiemmin käytetty eli siis kuinka kauan koneen käynnistymisestä on aikaa ja kuinka paljon tiedostojärjestelmiä on käytetty. En käynnistänyt konetta uudelleen ennen testiä, joten hidastumispiste on sattumanvarainen eikä siitä kannata vetää johtopäätöksiä. Muita vaikuttavia tekijöitä ovat keskusmuistin määrä ja sitä kautta välimuistin määrä ja tietysti välimuistin asetukset. Tärkeä havainto on hidastumisen määrä. Nopeus tippuu melko tarkalleen kolmannekseen. Mutta, kuten jo alussa huomautin, tulos on epätavallisen hyvä johtuen hitaasta keskusmuistista ja nopeasta SSD-levystä. Uudemmalla laitteistolla kymmenesosaan tai sitäkin pienempään hidastuminen olisi odotettavaa.

Loppupäätelmät

Tuloksia tulkitessa on otettava huomioon testilaitteiston erikoisuus. Sen takia SSD-levyllä tulokset ovat liian hyviä. Toisaalta testi oli täysin synteettinen ja tiedostot epätavallisen pieniä. Suurilla tiedostoilla erot nopeuksissa olisivat pienempiä. Ehkä nämä vastakkaiset vääristymät suurinpiirtein kumoavat toisensa, mutta varsinaisessa käytössä deduplikoituvuusastetta ei voi etukäteen tietää kuten ei tiedostojen kokoakaan.

Deduplikointia käytettäessä pätee edelleen kolmen käskyn optimointiohje:

- hanki lisää keskusmuistia

- hanki lisää keskusmuistia

- lisää SSD-levy välimuistilaitteeksi