ZFS:n evaluointia – 25. 12. 2011

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:

root@rk6:~# zpool replace tank c6t1d0 c12t50024E9203F93266d0

Tilanne levypoolissa näytti 10 tunnin kuluttua seuraavalta:

root@rk6:~# zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.  The pool will
        continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
 scrub: resilver in progress for 10h10m, 79,50% done, 2h37m to go
config:

        NAME                          STATE     READ WRITE CKSUM
        tank                          DEGRADED     0     0     0
          raidz3-0                    DEGRADED     0     0     0
            c6t0d0                    ONLINE       0     0     0
            replacing-1               DEGRADED     0     0     0
              c6t1d0                  UNAVAIL      0     0     0  cannot open
              c12t50024E9203F93266d0  ONLINE       0     0     0  1,00T resilvered
            c8t1d0                    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

errors: No known data errors

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:

root@rk6:~# zpool status tank
  pool: tank
 state: ONLINE
 scrub: resilver completed after 13h6m with 0 errors on Thu Dec 22 15:53:49 2011

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:

[root@rk7 ~]# ssh -l rk 192.168.0.16
Password:
Last login: Thu Dec 22 16:27:11 2011
Sun Microsystems Inc.   SunOS 5.11      snv_134 February 2010
rk@rk6:~$ /usr/bin/python2.6 /usr/ddu/ddu.py &

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.

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:

root@rk6:~# format
Searching for disks…done

AVAILABLE DISK SELECTIONS:
       0. c0t2d0
          /pci@0,0/pci10de,5d@e/pci15d9,400@0/iport@4/disk@p2,0

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

root@rk6:~# time dd if=/dev/zero of=/dev/dsk/c0t2d0s2 bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 148,344 s, 290 MB/s

real    2m28.389s
user    0m0.191s
sys     2m28.086s
root@rk6:~# time dd if=/dev/dsk/c0t2d0s2 of=/dev/null bs=1M count=20480
20480+0 records in
20480+0 records out
21474836480 bytes (21 GB) copied, 90,3149 s, 238 MB/s

real    1m30.342s
user    0m0.039s
sys     0m46.667s

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

root@rk6:~# swap -a /dev/dsk/c0t2d0s2

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

root@rk6:~# echo ”arc_meta_limit/Z 0x20000000” |  mdb -kw
arc_meta_limit: 0x30000000              =       0x20000000
root@rk6:~# echo ”::arc” |  mdb -k | grep meta_limit
arc_meta_limit            =       512 MB
root@rk6:~# time zdb -S tank

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