Nauhan käyttö varmistustallennukseen on vähentynyt ja sen on korvannut hyvin usein kiintolevy. Syitä voisi luetella useita, mutta ehkä tärkein ei ole se ilmeisin. Nauhan suosion lasku on ollut itseään ruokkiva kierre ja nauha on jäänyt kehityksestä jo liian kauas jälkeen. Kiintolevyn käyttö varmistustallennukseen ei sekään ole ongelmatonta, koska sitä ei alunperin siihen ole suunniteltu. Suurin tekijä, jonka ansiosta levy soveltuu nykyään jo varsin hyvin varmistustallennukseen on snapshottien eli tilannekuvien käyttö. Tilannekuvia ei vielä voi ottaa missä tahansa ympäristössä. Linuxissa se onnistui ensimmäisenä LVM:n (Logical Volume Management) avulla. LVM taas muuten on mielestäni jopa haitallinen. Se yrittää ratkaista tärkeitä ongelmia, mutta väärällä tavalla.

Tämä kirjoitus on eräällä tavalla jatkoa tai päivitys sekä ZFS-kirjoitussarjalle, josta kooste on luettavissa osoitteessa http://raimokoski.com/ZFS.php sekä http://rkoski.vapaavuoro.uusisuomi.fi/kulttuuri/99902-paranoidin-backup-resepti

Kuten edellämainituista kirjoituksista varmaan hyvin käy ilmi, on ZFS-tiedostojärjestelmä mielestäni aivan älyttömän hyvä. Eräs sen ominaisuuksista on tilannekuvat. Niiden käyttö on lisäksi hyvin helppoa. Se soveltuu siis erittäin hyvin varmistustallennukseen. Jos ZFS:stä haluaa etsiä huonoja puolia, on ehdottomasti tärkein verrattuna Linuxin ohjelmistopohjaiseen RAID-toteutukseen se, että koon kasvattaminen on hankalaa. ZFS-pakan koko täytyy siis päättää etukäteen käytännössä useiksi vuosiksi ja järkevin tapa kasvattaa sitä onkin usein koko laitteiston päivittäminen.

Toinen syy koko laitteiston vaihtoon minulla oli se, että vanhasta koneesta puuttui WOL-ominaisuus (Wake On Lan). WOL:n avulla kone voidaan herättää verkon kautta toiselta koneelta. Varmistuspalvelin voidaan siis käynnistää silloin, kun sitä tarvitaan ja tehtävien suorituksen jälkeen se voidaan sammuttaa. Sähköä siis säästyy. Olen pitänyt nyrkkisääntönä, että normaali pöytäkone syö kuukaudessa noin kympin arvosta sähköä ollessaan koko ajan päällä. Vuosien mittaan siitä kertyy kuitenkin useampi satanen. Itse kone voidaan tietysti sijoittaa siten, että sen humina tai muukaan läsnäolo ei liikoja häiritse, esimerkiksi komeroon tai autotalliin. Se on kuitenkin syytä suojata liialta pölyltä.

Uusi laitteisto

Olin jo aikaisemmin ostanut huuto.netin kautta kaksi HP:n Proliant ML 350 -palvelinta. Ne olivat kuitenkin eri sukupolvea, G5 ja vanhempi G4. G4 on jo niin vanha, että sain sen 60 € hintaan. G5:ssa taas oli enemmän keskusmuistia (6 Gt) ja pari kallista 10 000 rpm SAS-levyä. Siitä jouduin maksamaan peräti 250 €. Molemmat ostin kuitenkin lähinnä koska halvalla sain. G4 olisi ollut tavallaan sopivampi, mutta siinä keskusmuisti on selvästi hitaampaa kuin G5:ssa ja lähinnä sen ansiosta se yleensäkin on selvästi hitaampi. Prosessorin kellotaajuus G4:ssa on peräti 3 GHz, kun G5:ssa on kaksi ydintä 2 GHz taajuudella. Olen kuitenkin tullut siihen käsitykseen, että keskusmuistin nopeus on tärkein yksittäinen tietokoneen nopeutta kuvaava määre.

Tässä vaiheessa on hyvä muistuttaa, että tietokoneiden nopeuden kasvu lähes pysähtyi jo noin 10 vuotta sitten. John Dvorak väitti sen johtuneen Intelin Itanium-seikkailusta, mutta kyllä se ennemminkin johtui kellotaajuuden ylärajasta. Noin 10 vuotta sitten se oli nopeimmillaan noin 3 GHz, nyt se on noin 4 GHz eli kasvu on ollut mitätöntä. Onhan niitä ytimiä lisätty, mutta hyvin harvat tehtävät skaalautuvat rajattomasti. Jo kaksi ydintä riittää aivan mainiosti lähes kaikkeen. Vanhat palvelinkoneet ovat siis varsin käyttökelpoisia edelleen ja luotettavia alustoja “projekteille”.

Näistä vähän turhista minulla jo noin vuoden olleista koneista lähdin sitten yhdistelemällä kasaamaan levypalvelinta. G4:sta tarvitsin vain levykehikkoa. G5:ssä oli muuten samanlainen kehikko, mutta 2,5″ levyille. Harkitsin 2,5″ kehikon poistoa, mutta SAS-levyissä SAS- ja virtaliittimet olivat tavallaan yhdessä eikä niiden välissä ollut tavanomaista koloa. Niille olisi siis pitänyt hankkia erikoinen johto tai luopua niiden käytöstä. Onneksi G4:n levykehikko on melko tarkkaan neljän 5,25″ levypaikan korkuinen ja G5:ssä niitä on viisi. Yhden käyttää DVD-asema, joten levykehikko sopi melkoisen tiukasti vapaaseen tilaan. Sivulle jäi aukko, mutta tukin sen viivottimella, jonka pituuden sovitin tiukasti väliin, johon sen asetin. Levykehikon yläpään kiinnitysulokkeet poistin levysaksilla ja pyöristin leikkausjäljen viilalla. Alapään kiinnitysulokkeiden kohdalle koneen runkoon porasin reiät ja kierteitin ne M5:n kierretapilla. Koska levykehikko on pystysuunnassa piukasti paikallaan, riittää kaksi kiinnitysruuvia mainiosti.

G4:n levykehikossa oli ollut vain kaksi levykelkkaa, joten tarvitsin vielä neljä lisää. Sain ostettua ne samalta myyjäliikkeeltä, jolta olin koneetkin ostanut huuto.netin kautta. Hinta oli 1 €/kpl ja postituskulut olivat suuremmat kuin itse ostos. Levykehikkoon tulisi siis kuusi 3,5″ levyä, mutta olin päätynyt siihen, että tarvitsisin kahdeksan levyä. Yhden sain sopimaan G5:n alkuperäiseen levykehikkoon, mutta kiinnitykseen jouduin poraamaan kehikkoon pari reikää, viistämään ne, jotta uppokantaiset ruuvit uppoaisivat riittävän syvälle, jotta kehikko mahtuisi koneen runkoon ruuvien kannoista huolimatta. Toiselle levylle löytyi sopiva paikka tukirimasta, jossa sattui vielä olemaan sopivan kokoinen valmis reikä vasrin sopivassa paikassakin. Toista reikää sen kiinnitykseen en viitsinyt porata. Pysyy se levy yhdelläkin ruuvilla paikallaan.

G5:ssa oli valmiina jo peräti 6 Gt keskusmuistia, 4 * 1 Gt ja 4 * 0,5 Gt kampaa. Vanhassa OpenIndiana-koneessa oli vain 4 Gt ja se oli samalla emolevyn maksimimäärä. ZFS:ssä oli ollut melko vakava ongelma snapshottien poistossa, mutta se oli korjattu joko versiossa 26 tai 27, jotka molemmat korjasivat snapshottien ongelmia. Aiemmin snapshottien poisto vaati erittäin paljon keskusmuistia tai sitten hyvää tuuria. Lopputulos oli, että snapshottien poisto toimi silloin, kun sitä huvitti ja jos ei toiminut, kone tilttasi. Nykyinen versio on 28 eikä ongelmaa ole pitkään aikaan ilmennyt, mutta silti lisämuisti rauhoittaisi mieltä. G5:een saa ilmeisesti jopa 32 Gt keskusmuistia (8 * 4 Gt), mutta se olisi tullut jo liian kalliiksi mielestäni. Koneet myyneestä liikkeestä muistia ei löytynyt, mutta eBaystä löytyi useitakin myyjiä. Päädyin kahden gigan kampoihin, joilla korvaisin puoligigaiset. Hintaa postikuluineen USA:sta 36 €. Neljägigaiset olisivat maksaneet lähes satasen ja niillä kokonaismäärä olisi noussut 20:een, mutta 12 Gt sai riittää.

ZFS:n version saa esille käskyllä:

# zpool upgrade -v
.....
The following legacy versions are also supported:

VER  DESCRIPTION
---  --------------------------------------------------------
.....
 26  Improved snapshot deletion performance
 27  Improved snapshot creation performance
 28  Multiple vdev replacements

Kiintolevyjen kapasiteetti jäi edellä mainitsematta. Vanhassa koneessa oli ollut 10 kpl kaksiteraisia, joista kaksi pariteetille eli varsinaiseen käyttöön jäi 16 teraa. Se oli käytössä jo yli 70-prosenttisesti, mutta käyttöasteen kasvu on ollut melko hidasta. 24 teraa saisi siis riittää ja 8 neliteraista, joista kaksi pariteetille tuottaisi juuri sen. Käyttöaste tippuisi noin 50 %:iin, joka on aika järkevä aloituspiste.

Kaksi teraa on kiintolevyille ollut aika vaikea raja. Perinteisellä puolen kilon sektorikoolla sen osoitukseen tarvitaan 32 bittiä ja juuri sen verran on varattu mm. osiotauluun osion kooksi, lopetuskohdaksi jne. 32 bittiä on myös monessa muussa paikassa rajana. Niin myös G5:n SAS-adapterin BIOS:sissa ja yllättäen myös vanhasta koneesta siirretyssä SuperMicron AOC-USAS2-adapterissa. Hewlett-Packard Company Smart Array E200i (SAS Controller), kuten Linuxin lspci G5:n omaa adapteria kutsuu, ajattelin ensin päivittää, mutta googlaus tuotti laihasti tuloksia. Lisäksi kun se oli se adapteri, jossa käynnistyslevyjen pitäisi olla kiinni, olisi sen BIOS:in päivitys hieman riskialttiimpaa. Vaikka se on 8-porttinen, siitä voisi hyödyntää vain neljä. Emolevyltä levykehikon backplanelle tuli kaksi johtoa, kumpikin neljälle levylle. Minulla oli jo valmiina hieman erikoinen johto, jossa on sama leveä liitin kuin G5:n emolla ja toisessa päässä se haarautuu neljään normaaliin SAS/SATA-johtoon. Se on nyt koneessa paikallaan, mutta toistaiseksi hyödyntämättä. E200i on tietysti vain SAS1-tasoa eli hitaahko, BIOS:kin vielä päivittämättä ja lisälevyt pitää määritellä oudoilla komentoriviohjelmilla, käynnistyksen aikana BIOS:n kautta se ei onnistu. Ihme värkki. Sen Linux-tuki HP:n rpm-repositoreista on kyllä moitteeton, onhan Linux yleensäkin palvelinkoneissa ollut jo pitkään yleisin käyttöjärjestelmä. OpenIndiana- tai siis Solaris-tuesta en olisi lainkaan yhtä vakuuttunut.

Vanhasta koneesta siirtyi siis 8-porttinen SAS2-adapteri ja OpenIndiana tuki PCI-e-väyläistä kahden portin SATA-adapteriakin, jonka Linuxin lspci tunnistaa nimellä “Silicon Image, Inc. SiI 3132 Serial ATA Raid II Controller”. Kävin taas läpi kaikki muutkin vapaat SATA-adapterini, mutta niitä OpenIndiana ei tukenut. 10 porttia riittäisi silti ja optiona vielä E200i:n neljä porttia.

AOC-USAS2 tai “LSI Logic / Symbios Logic SAS2008 PCI-Express Fusion-MPT SAS-2 [Falcon] (rev 02)” kuten lspci sen näkee piti siis fläshätä. Dosin boottilevy USB-tikulle ja kaikkea muuta antiikkista sähläystä. AOC-USAS2:n BIOS:ia on useita erilaisia versioita. IT-moodi (Initiator – Target) on se yksinkertaisin, pelkkä HBA, ei mitään RAID-tasoja ja ajattelin sen sopivan parhaiten OpenIndianalle. Jotain kuitenkin mätti ja päädyin IR-moodiin, jossa AOC-USAS2 oli alunperinkin ollut, ja ilmeisesti syystäkin. Siinä on optiona myös RAID, mutta ei se ilmeisesti haittaa. Linuxin mdadm:llä testasin RAID-6:n nopeuksia ja hdparm kertoi lukunopeuden olevan siinä 700 Mt/s, ehkä aavistuksen verran nopeampi IR-moodissa.

Niin ne levyt vielä tarkemmin. Seagaten Barracuda Desktop 4TB 5900RPM HDD SATA 6Gb/s 3.5″ 64MB, malli ST4000DM000-1F2168. SAS2 on yhtä nopea kuin SATA3, joten ihan sopivia AOC-USAS2:lle. Hdparm kertoo levyn lukunopeudeksi noin 148 Mt/s, joka on varsin hyvin hitaahkolla kierrosnopeudella, joka taas tarkoittaa vähäistä lämpenemistä ja toivottavasti myös pitkää ikää. Lisäksi kaikkein halvin kaupasta löytyvä neliterainen.

Käyttöjärjestelmän asennus

Yritin tietysti asentaa uusimman OpenIndianan, kun olin ensin pienentänyt SAS-levyille, jotka olivat E200i:ssä määritelty RAID1:ksi eli peilipariksi, asennetun Scientific Linux 6.x:n osiota puoleen. Asennus kuitenkin keskeytyi asennusohjelman alustaessa levyä kohdassa 2 % valmiina. Sama toisella yrityksellä uudelle DVD-aihiolle poltetulla asennuslevyllä. No, lisäsin 320-gigaisen SATA-levyn ja sille asennus sujuikin, mutta käynnistyksessä ruudulle lävähti roskaa punaisella taustalla. Samat operaatiot OpenSolaris 134 SVN:n kanssa (viimeisin Sunin julkaisema versio, jota saa vapaasti käyttää) ja samat tulokset. OpenIndianan tekstimoodiasennuslevyäkin vielä kokeilin, mutta ei siitäkään ollut apua.

Tässä vaiheessa tietysti muut vaihtoehdot alkoivat kiinnostamaan. ZFS on ollut pitkään saatavilla muille käyttöjärjestelmille, mutta Linuxissa FUSE:n varaan rakennettu toteutus ei oikein ollut kiinnostanut. Se olisi ollut todennäköisesti melkoisen hidas. FreeBSD:ssä ZFS on ollut ilmeisesti varsin hyvin tuettu, mutta FreeBSD taas ei kiinnostanut.

OpenIndiana ja jo sitä ennen OpenSolaris oli jatkuvasti harmittanut heikon laitetukensa takia. 8-porttiset AOC-USAS ja uudempi AOC-USAS2 ovat hyviä ja edullisia SAS/SATA-adaptereita, mutta siinä sitten onkin lähes kaikki järkevän hintaiset vaihtoehdot, jos Solaris-pohjalle haluaa useamman levyn levypalvelimen rakentaa. Emolevyjen omat SATA-liitännät ovat hyvin harvoin tuettuja ja vanha OpenIndiana-koneeni oli tietääkseni ainoa koneistani, jonka emon liitännät kelpasivat. Asiat ovat hyvin heikosti käyttöjärjestelmällä, jos levyliitännät tuottavat ongelmia. Lisäksi OpenIndianan ja muidenkin OpenSolariksen perinteenjatkajien taustayhteisö ja yhteistyöprojekti Illumos ei vaikuttanut kovin suurelta menestykseltä. OpenIndianakin on ollut saatavana vain vakaana beta-versiona vaikka lopullinen versio piti julkaista jo noin vuosi sitten. Postituslistoilla lisäksi kitinää, että se ja se ei käänny, kun keskeisiä kirjastoja ei ole kunnolla portattu ja muuta hankaluutta, joihin ei viitsisi aikaansa uhrata.

Ja lopulta olin kaivannut vain yhtä OpenSolarikselta ja sen perillisiltä: ZFS:ää.

ZFS on Linux

ZFS oli siis ollut pitkään saatavana Linuxille FUSE-modulina, mutta jo noin pari vuotta myös Linuxin ytimen modulina ja vakaana versiona vuoden. Sunin SDL-lisenssi ei ole yhteensopiva GPL:n kanssa, mutta jos ZFS-moduleja levitetään erikseen, voivat ne olla myös ytimen moduleja. No, käyttäjälle ihan sama, ZFS on nyt kunnolla tuettu Linuxissa.

Asennus RHEL-pohjaisiin on yksinkertainen:

yum localinstall --nogpgcheck http://archive.zfsonlinux.org/epel/zfs-release-1-3.el6.noarch.rpm
yum install zfs

Ensin repositoryn määrittelytiedosto ja sitten asennus.

Ai niin, Linuxin ZFS-toteutusta rahoittaa USA:n puolustusministeriö, kotisivu on  http://zfsonlinux.org/ ja sitä ylläpitää Lawrence Livermore National Laboratory.

Toistaiseksi Linuxin ZFS-toteutusta ei ole yritetty optimoida nopeuden suhteen, joten se pitäisi vielä testata.

Sitä ennen kuitenkin Linux-asennuksen korjaus. Käynnistyslataaja grub nimittäin heitti samaa roskaa punaisella pohjalla kuin OpenIndianakin oli tehnyt. Käynnistys Scientificin asennuslevyltä vikasietoon ja grubin asennus uudelleen ratkaisi ongelman. Taisi samalla selvitä OpenIndianan asennusongelma ainakin osittain. Se oli johtunut grubista, jota myös OpenIndiana käyttää. Miten se olisi ollut korjattavissa, en tiedä, mutta nyt se olisi helpommin selvitettävissä. Ainakin aikaisemmin grub tuki vain kahdeksaa levyä ja koneessa oli niitä 9 ja välillä 10 (E200i:n peilipari laskettuna vain yhdeksi levyksi).

Nyt ei enää olisi ongelmia levyadapterien kanssa, kaikki toimisivat. Myös se Adaptecin neliporttinen PCI-e-väyläinen ja muutama neliporttinen PCI-väyläinen. Levyjä saisi niiden puolesta olla yli 20 kpl ja ongelmat olisivat jo fyysisellä puolella.

ZFS on Linux käytännössä

Linuxille sovitettu ohje löytyy osoitteesta https://pthree.org/2012/04/17/install-zfs-on-debian-gnulinux/ Ei se juurikaan poikkea Solariksen dokumentaatiosta, mutta pieniä eroja on ja Aaronin opas on aika kompakti. Sen voi lukea vaikka kertauksena ja esimerkiksi yli 2 Tt levyjen käsittelystä en muista Solariksen dokuista aikoinaan lukeneeni.

Kirjoitusnopeus

Linuxissakaan ZFS:n tai oikeammin zpoolin nopeuden testaamiseen ei voi käyttää hdparm-ohjelmaa, joka on muodostunut levyjen nopeustestauksessa jonkinlaiseksi standardiksi. Zpool ei nimittäin luo laitetiedostoa kuten mdadm eli Linuxin RAID-toteutus tekee. Käytämme siis samoja testaustapoja kuin OpenSolariksessa aikoinaan.

sync ; time ( dd if=/dev/zero of=test40G bs=1M count=40960 ; sync )
40960+0 tietuetta sisään
40960+0 tietuetta ulos
42949672960 tavua (43 GB) kopioitu 166,281 sekunnissa, 258 MB/s

real    10m25.915s
user    0m0.113s
sys     0m50.231s

Nyt time-käskystä on hyötyä. dd luulee, että testitiedosto on kirjoitettu levylle, mutta oikeasti se on levyllä vasta sync-komennon suorituksen jälkeen, joten joudumme laskemaan ja kirjoitusnopeus onkin huomattavasti huonompi.

[root@rk4 tank]# echo | awk '{print 42949672960/625.915/1024/1024}'
65.4402

Vielä toinen tiedosto, jotta saadaan välimuistit tyhjenemään ja mittaustulos varmistettua.

[root@rk4 tank]# sync ; time ( dd if=/dev/zero of=test40-2G bs=1M count=40960 ; sync )
40960+0 tietuetta sisään
40960+0 tietuetta ulos
42949672960 tavua (43 GB) kopioitu 162,08 sekunnissa, 265 MB/s

real    9m48.990s
user    0m0.125s
sys     0m49.835s
[root@rk4 tank]# echo | awk '{print 42949672960/588.99/1024/1024}'
69.5428

Keskiarvo on 67.4915 Mt/s.

Lukunopeus:

[root@rk4 tank]# sync ; time ( dd if=test40G of=/dev/null bs=1M count=40960 ; sync )
40960+0 tietuetta sisään
40960+0 tietuetta ulos
42949672960 tavua (43 GB) kopioitu 76,6077 sekunnissa, 561 MB/s

real    1m16.613s
user    0m0.140s
sys     0m47.864s

Aikamoisen nopea eikä tarvitse laskea.

[root@rk4 tank]# sync ; time ( dd if=test40-2G of=/dev/null bs=1M count=40960 ; sync )
40960+0 tietuetta sisään
40960+0 tietuetta ulos
42949672960 tavua (43 GB) kopioitu 76,0706 sekunnissa, 565 MB/s

real    1m16.076s
user    0m0.122s
sys     0m48.906s

Sektorikoon vaikutus yli 2 Tt levyillä

Kahden teratavun kokorajoitus levyillä löytyy useasta paikasta ja eräs keino kiertää sitä on sektorikoon kasvattaminen 512 tavusta esimerkiksi neljään kilotavuun. Varsinaista ongelmaa sektorikoon muuttaminen siirtää vain muutamalla vuodella eteenpäin, mutta toisaalta perinteinen sektorikoko on nykyisin epäkäytännöllisen pieni. Sen takia yli 2 Tt kokoisilla levyillä tyypillinen aito sektorikoko onkin 4 kt, mutta levyt oletuksena väittävät sen olevan 512 t ja hoitavat erosta johtuvan piilotustyön salassa. Suorituskyvyn kannalta aidon sektorikoon käyttö on ainakin teoriassa merkittävä nopeuttaja.

Tiesin kyllä sektorikoon mahdollisesta vaikutuksesta, mutta minulla oli kiire päästä kokeilemaan uutta levyjärjestelmää ja yleisenä periaatteena on ihan hyvä käyttää ainakin alussa oletusasetuksia. Sektorikooksi tuli siis alussa 512 t. Tämä alkoi pian huolestuttaa varsinkin kun kirjoitusnopeus oli vaatimaton. Zpoolin käyttämä sektorikoko pitää valitettavasti määritellä luontivaiheessa, joten väärällä sektorikoolla varustettu pooli pitää poistaa ja luoda sen tilalle uusi. Onneksi se on hyvin nopea operaatio. Tiedostojen kopiointi uudelleen ei taas ole niin nopeaa. 11 teraa kopioituu nopeimmillaan noin 37 tunnissa ja pienet tiedostot hidastavat operaatiota edelleen.

Alla vanhan poolin poisto ja uuden luonti 4 kt sektorikoolla:

# zpool destroy tank
# zpool create -f -o ashift=12 tank raidz2 sda sdb sdc sdd sde sdf sdg sdh
# zpool add tank cache sdi
# zpool add -f tank log sdj

Tämän jälkeen nopeustestien tulokset lyhyesti. Ensimmäisen testitiedoston kirjoitus oli lupaavan nopeaa, noin 260 Mt/s, mutta ilmeisesti se kirjoitettiin vasta välimuistilaitteelle, koska seuraavan testitiedoston luonti oli jo yhtä hidasta kuin pienemmällä sektorikoolla.

real    10m33.184s
real    9m16.032s
[root@rk4 tank]# echo | awk '{print 42949672960/633.184/1024/1024}'
64.6889
[root@rk4 tank]# echo | awk '{print 42949672960/556.032/1024/1024}'
73.6648

Kirjoitusnopeuden keskiarvo oli siis 69 Mt/s. On se 1,5 Mt/s nopeampi kuin aiemmin, mutta ero selittyy helposti mittausepätarkkuudella.

Lukunopeudet lyhyesti:

42949672960 tavua (43 GB) kopioitu 73,9544 sekunnissa, 581 MB/s
42949672960 tavua (43 GB) kopioitu 75,631 sekunnissa, 568 MB/s
42949672960 tavua (43 GB) kopioitu 74,4682 sekunnissa, 577 MB/s

Keskiarvo on 575.333 Mt/s, joka sekin on hieman nopeampi kuin pienemmällä sektorikoolla.

Sektorikoon vaikutus nopeuteen on siis mitätön. Linuxin zfs-toteutusta ei ole vielä optimoitu nopeuden suhteen, joten tulevaisuudessa kirjoitusnopeuskin todennäköisesti paranee lähelle OpenSolariksen/OpenIndianan tasoa. Tällä hetkellä kirjoitusnopeus on lähes riittävä, koska seuraava rajoittava tekijä on verkon nopeus. Jos Linuxin zfs-toteutus olisi optimoitu, olisi kirjoitusnopeuden käytännön maksimi noin 110 Mt/s johtuen gigabitin ethernetistä.

Seuraavassa osassa

Ne varmistustallennusskriptit pitää vielä viimeistellä, lisätä mm. wol-käsky, odotusaika, jonka kone tarvitsee herätäkseen sekä snapshottien käsittely. OpenIndianassa on kätevä timeslider, jolla snapshotteja voi hallita graafisesti sekä valmiit skriptit cronille. ZFS on Linuxissa ei näitä vakiona ole, mutta netistä löytyy kyllä useitakin valmiita skriptejä. Niitä vain ei ihan sellaisenaan suoraan uskalla ottaa käyttöön. Odotettavissa siis päivitetty paranoidin backup-resepti.