ZFS:n evaluointia

Päivitetty 18. 12. 2011. ZFS eli Zettabyte File System on 128-bittisenä käsittämättömän iso. Linuxin vakiotiedostojärjestelmässä ext4:ssä raja on surkea 16 Tt. ZFS kiinnostaa ja sen muut hienot ominaisuudet, kuten deduplikointi.

 

 

Tästä blogikirjoituksesta

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

En anna mitään takeita siitä kuinka usein lisään tekstiä. Tällä hetkellä minulla on jonkinlainen lievä keuhkokuume ja kirjoittaminen on mielekkäintä hommaa.

 

 

Kuvat

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.

 

15. 12. 2011

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:

NAME
       hardlink – Consolidate duplicate files via hardlinks

SYNOPSIS
       hardlink [-c] [-n] [-v] [-vv] [-h] directory1 [ directory2 … ]

DESCRIPTION
       This  manual  page  documents  hardlink,  a  program which consolidates
       duplicate files in one or more directories using hardlinks.

       hardlink traverses one or  more  directories  searching  for  duplicate
       files.   When it finds duplicate files, it uses one of them as the mas-
       ter.  It then removes all other duplicates and places  a  hardlink  for
       each  one pointing to the master file.  This allows for conservation of
       disk space where multiple directories on a  single  filesystem  contain
       many duplicate files.

       Since  hard  links  can only span a single filesystem, hardlink is only
       useful when all directories specified are on the same filesystem.

OPTIONS
       -c        Compare only the contents of the files being  considered  for
                 consolidation.   Disregards  permission,  ownership and other
                 differences.

       -n        Do not perform the consolidation; only print  what  would  be
                 changed.

       -v        Print summary after hardlinking.

       -vv       Print  every hardlinked file and bytes saved. Also print sum-
                 mary after hardlinking.

       -h        Show help.

AUTHOR
       hardlink was written by Jakub Jelinek .

       Man page written by Brian Long.

       Man page updated by Jindrich Novy

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ä

# df
Tiedostojärjestelmä  1K-lohkot  Käytetty   Vapaana Käy% Liitospiste
/dev/md0             15382877564 8019410656 6582160904  55% /mirrors
# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdi[10](S) sdf[0] sdb[9] sdk[8] sdg[7] sdc[6] sdl[5] sde[4] sdd[3] sdh[2] sdj[1]
      15628115968 blocks level 6, 64k chunk, algorithm 2 [10/10] [UUUUUUUUUU]

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:

[root@rk7 mirrors]# find . -exec md5sum ”{}” >> mirrors.md5sum4 ;

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.

# ls -lh /mirrors/mirrors.md5sum*
-rw-r–r– 1 root root 155M  1.5.2011 /mirrors/mirrors.md5sum

# cd /mirrors/
[root@rk7 mirrors]# time sort mirrors.md5sum > mirrors.md5sum.srt

real    0m12.162s
user    0m9.621s
sys     0m0.634s

Tiedoston koko ja sorttausaika ovat sen takia mielenkiintoisi, 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.

# echo | awk ’{print 8019410656/128*32/1024/1024/1024″ Gt”}’
1.86716 Gt

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

Effective use of deduplication requires additional hardware. ZFS designers recommend 2 GB of RAM for every 1 TB of storage. Example: at least 32 GB of memory is recommended for 20 TB of storage. [31] If RAM is lacking, consider adding an SSD as a cache, which will automatically handle the large de-dupe tables. This can speed up de-dupe performance 8x or more. Insufficient physical memory or lack of ZFS cache results in virtual memory thrashing, which lowers performance.

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

[root@rk7 mirrors]# uniq –check-chars=32 mirrors.md5sum.srt > mirrors.md5sum.unq
# Luotiin uniikkien md5-summien lista
[root@rk7 mirrors]# diff mirrors.md5sum.srt mirrors.md5sum.unq | wc -l
940891

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

[root@rk7 mirrors]# diff mirrors.md5sum.srt mirrors.md5sum.unq | head
3d2
< 000028f474c0173a208ca0e3b052521f  ./hda3/var/cache/ccache/d/5/d834c2972ad5db91121b589819f9d7-285692
8,10d5
< 0000acdabe87d48a6fcceccf0d17d6a0  ./hda3/root/Linuxkurssi-3/fc8/firstboot-1
[root@rk7 mirrors]# diff mirrors.md5sum.srt mirrors.md5sum.unq |

     awk ’{if ($1 == ” mirrors.md5sum.fls
# tiedostoon tulostettiin vain duplikaattien tiedostonimet
[root@rk7 mirrors]# du –summarize `cat mirrors.md5sum.fls`
bash: /usr/bin/du: Argumenttilista on liian pitkä
[root@rk7 mirrors]# wc -l mirrors.md5sum.fls
630719 mirrors.md5sum.fls
# Tuo oli tiedostojen määrä.
[root@rk7 mirrors]# awk ’{sub(”^  ”,””);system(”du ””$0″” >> mirrors.md5sum.fs”)}’

      mirrors.md5sum.fls

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

[root@rk7 mirrors]#  awk ’{SUM+=$1};END{print SUM/1024/1024″ Gt”}’ mirrors.md5sum.fs ;  wc -l mirrors.md5sum.fs
735.982 Gt
397883 mirrors.md5sum.fs

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

[root@rk7 mirrors]#  awk ’{SUM+=$1};END{print SUM/1024/1024″ Gt”}’ mirrors.md5sum.fs
819.485 Gt

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:

find . -type f -exec md5sum ”{}” >> mirrors.md5sum4 ;

Käynnistin tuon 01:31 ja nyt

#  ls -lh mirrors.md5sum*
-rw-r–r– 1 root root 155M  1.5.2011 mirrors.md5sum
-rw-r–r– 1 root root 6,6M 16.12. 07:31 mirrors.md5sum4

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

PRC | sys   7.52s | user  26.00s | #proc    303 | #zombie    1 | #exit      8 |
CPU | sys     63% | user    260% | irq      14% | idle     51% | wait     12% |
cpu | sys     28% | user     67% | irq       2% | idle      4% | cpu000 w  0% |
cpu | sys     14% | user     66% | irq       3% | idle     13% | cpu002 w  5% |
cpu | sys     14% | user     62% | irq       4% | idle     14% | cpu001 w  5% |
cpu | sys      7% | user     64% | irq       6% | idle     20% | cpu003 w  2% |
CPL | avg1   2.56 | avg5    2.81 | avg15   2.84 | csw    98525 | intr   99574 |
MEM | tot    7.8G | free   51.9M | cache 956.8M | buff   66.8M | slab  113.5M |
SWP | tot   14.9G | free   14.7G |              | vmcom  10.2G | vmlim  18.8G |
PAG | scan 704996 | stall      0 |              | swin       0 | swout      0 |
DSK |         sdk | busy     50% | read    4460 | write      5 | avio    1 ms |
DSK |         sdl | busy     49% | read    4339 | write      6 | avio    1 ms |
DSK |         sdf | busy     42% | read    4476 | write      4 | avio    0 ms |
DSK |         sde | busy     40% | read    4472 | write      6 | avio    0 ms |
DSK |         sdb | busy     31% | read    4234 | write      7 | avio    0 ms |
DSK |         sdj | busy     30% | read    4231 | write      4 | avio    0 ms |
DSK |         sdc | busy     20% | read    4465 | write      5 | avio    0 ms |
DSK |         sdh | busy     19% | read    4475 | write      4 | avio    0 ms |
DSK |         sdd | busy     19% | read    4357 | write      4 | avio    0 ms |
DSK |         sdg | busy     19% | read    4259 | write      4 | avio    0 ms |
DSK |         sda | busy      1% | read      35 | write     40 | avio    1 ms |

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.

[root@rk7 mirrors]# du -sh avi/
6,5T    avi/
[root@rk7 mirrors]# find avi -type f | wc -l
10429
[root@rk7 mirrors]# du -sh mp3/
176G    mp3/
[root@rk7 mirrors]# find mp3 -type f | wc -l
63402

No, joka tapauksessa syntyi

-rw-r–r– 1 root root 163M 16.12. 12:46 mirrors.md5sum4
[root@rk7 mirrors]# wc -l mirrors.md5sum4
1620736 mirrors.md5sum4

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

[root@rk7 mirrors]# hdparm -tT /dev/md0

/dev/md0:
 Timing cached reads:   6914 MB in  2.00 seconds = 3458.65 MB/sec
 Timing buffered disk reads:  994 MB in  3.00 seconds = 330.87 MB/sec

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:

[root@rk7 mirrors]# time sort mirrors.md5sum4 > mirrors.md5sum4.srt

real    0m12.463s
user    0m10.473s
sys     0m0.464s
# sortataan, jotta uniq toimisi
[root@rk7 mirrors]# uniq –check-chars=32 mirrors.md5sum4.srt > mirrors.md5sum4.unq
# uniikit md5-summat
[root@rk7 mirrors]#  diff mirrors.md5sum4.srt mirrors.md5sum4.unq |

       awk ’{if ($1 == ” mirrors.md5sum4.fls
# Duplikaattien tiedostonimet
[root@rk7 mirrors]#  wc -l mirrors.md5sum4.fls
665046 mirrors.md5sum4.fls
# Duplikaattinen määrä
root@rk7 mirrors]# time awk ’{sub(”^  ”,””);system(”du ””$0″” >> mirrors.md5sum4.fs”)}’

      mirrors.md5sum4.fls
real    94m17.791s
user    8m0.077s
sys     14m55.389s
# Duplikaattien koot. Ajoaika selvästi lyhyempi kuin eilen, jolloin laskettiin samaan aikaan myös md5-summia.
[root@rk7 mirrors]#  awk ’{SUM+=$1};END{print SUM/1024/1024″ Gt”}’ mirrors.md5sum4.fs
812.031 Gt
# Ja yhteiskoko.

Jatkon osalta suunnitelma on seuraava: Odotan SSD-levyä, jotta koko rsyncillä peilattava mirrors:in kopio voidaan deduplikoida OpenSolariksessa. Nyt tiedetään, miten paljon deduplikoitavaa olisi tiedostotasolla, noin 10 %. En poista duplikaatteja, vaan annan ZFS:n automatiikan hoitaa sen. Blokkitasolla pystyy poistamaan kaikki tiedostotasolla esiintyvät duplikaatit ja sen lisäksi vielä hiukan lisää. Kuinka paljon enemmän, on mielenkiintoista. Ennen SSD-levyn saapumista voisi olla hyvä esitellä OpenSolarikselle annettua laitteistoa ja testata levyjärjestelmän nopeus uudemmalla SAS2-adapterilla. Kiintolevyt ovat SATA-II-tyyppisiä, joten levyjen ja adapterin väli ei nopeudu, mutta väli adapterista PCI-e-väylälle ja eteenpäin voi nopeutua.

Sitten tietysti kopiointi rsyncillä, joka vie ainakin vuorokauden. Nyt tehtyä md5-summatiedostoa voi lisäksi käyttää paranoian lievittämiseksi. Olen jo aikaisemmin yrittänyt samaa, mutta silloin deduplikointi hidasti ihan älyttömästi. Wikipedian ZFS-sivu, http://en.wikipedia.org/wiki/ZFS on todella hyvä. Sunin tai nykyään Oraclen tuottama materiaali on niin laajaa, että sen kahlaamiseen menee paljon aikaa. Lisäksi tärkeää tietoa, kuten missä muissa käyttöjärjestelmissä ZFS toimii, ei Oraclen dokumentaatiosta varmaankaan löydy. Vastaavaa vertailua kuin nyt olen tekemässä, tuskin ainakaan pienellä hakemisella kuitenkaan löytyy.

Aikaisemmalla kerralla rinnakkaisprojektina oli verkon nopeuden lisääminen Ethernet bonding -tekniikalla, mutta kahden koneen väliä en saanut nopeutettua. Se kyllä onnistui, että yksi kone oli ”serveri” kolmella yhteensidotulla 1 Gbps kortilla ja kolme ”asiakasta” imivät parhaimmillaan yhteensä 2,6 Gbps.

Sain antibiottikuurin keuhkokuumeeseen. Kirjoittaminen varmaan vähenee, kun liikkuminen ei niin väsytä..

 

17. 12. 2011

Vilkaistaan OpenSolaris-konetta ja sen levyjä:

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

AVAILABLE DISK SELECTIONS:
       0. c4d0
          /pci@0,0/pci-ide@6/ide@0/cmdk@0,0
       1. c6t0d0
          /pci@0,0/pci1043,815a@8/disk@0,0
       2. c6t1d0
          /pci@0,0/pci1043,815a@8/disk@1,0
       3. c7t0d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@0,0
       4. c7t1d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@1,0
       5. c7t2d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@2,0
       6. c7t3d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@3,0
       7. c7t4d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@4,0
       8. c7t5d0
          /pci@0,0/pci10de,5d@e/pci15d9,a580@0/sd@5,0
       9. c8t1d0
          /pci@0,0/pci1043,815a@7/disk@1,0
Specify disk (enter its number): ^C

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

root@rk6:/tank# zpool history tank | grep create
2011-04-22.11:20:51 zpool create tank raidz3 c6t0d0 c6t1d0 c7t0d0 c7t1d0 c7t2d0 c7t3d0 c7t4d0 c7t5d0 c8t1d0
2011-04-22.11:21:20 zfs create tank/mirrors
2011-04-22.11:21:28 zfs create tank/mirrors/avi
2011-04-22.11:22:31 zfs create tank/mirrors/mp3

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:

 

zfs get all tank
NAME  PROPERTY               VALUE                        SOURCE
tank  type                   filesystem                   –
tank  creation               pe huhtikuuta 22 11:20 2011  –
tank  used                   7,43T                        –
tank  available              3,36T                        –
tank  referenced             57,9K                        –
tank  compressratio          1.00x                        –
tank  mounted                yes                          –
tank  quota                  none                         default
tank  reservation            none                         default
tank  recordsize             128K                         default
tank  mountpoint             /tank                        default
tank  sharenfs               off                          default
tank  checksum               on                           default
tank  compression            off                          default
tank  atime                  on                           default
tank  devices                on                           default
tank  exec                   on                           default
tank  setuid                 on                           default
tank  readonly               off                          default
tank  zoned                  off                          default
tank  snapdir                hidden                       default
tank  aclmode                groupmask                    default
tank  aclinherit             restricted                   default
tank  canmount               on                           default
tank  shareiscsi             off                          default
tank  xattr                  on                           default
tank  copies                 1                            default
tank  version                4                            –
tank  utf8only               off                          –
tank  normalization          none                         –
tank  casesensitivity        sensitive                    –
tank  vscan                  off                          default
tank  nbmand                 off                          default
tank  sharesmb               off                          default
tank  refquota               none                         default
tank  refreservation         none                         default
tank  primarycache           all                          default
tank  secondarycache         all                          default
tank  usedbysnapshots        0                            –
tank  usedbydataset          57,9K                        –
tank  usedbychildren         7,43T                        –
tank  usedbyrefreservation   0                            –
tank  logbias                latency                      default
tank  dedup                  off                          default
tank  mlslabel               none                         default

tank  com.sun:auto-snapshot  true                         local

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

root@rk6:/tank/mirrors# cd ..
root@rk6:/tank# sync ; time ( dd if=/dev/zero of=test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 313,683 s, 137 MB/s

real    5m14.170s
user    0m0.128s
sys     1m4.100s
root@rk6:/tank# sync ; time ( dd if=/dev/zero of=test40-2G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 374,068 s, 115 MB/s

real    6m16.188s
user    0m0.138s
sys     1m3.264s

Kirjoitusnopeuden keskiarvo on 126 Mt/s

 

root@rk6:/tank# sync ; time ( dd if=test40G of=/dev/null bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 197,585 s, 217 MB/s

real    3m18.187s
user    0m0.125s
sys     1m15.852s
root@rk6:/tank# sync ; time ( dd if=test40-2G of=/dev/null bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 203,741 s, 211 MB/s

real    3m24.431s
user    0m0.163s
sys     1m20.102s

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:

rk@rk6:~$ su – root
Password:
Sun Microsystems Inc.   SunOS 5.11      snv_134 February 2010
root@rk6:~# format
Searching for disks…done

AVAILABLE DISK SELECTIONS:
       0. c4d0
          /pci@0,0/pci-ide@6/ide@0/cmdk@0,0
       1. c6t0d0
          /pci@0,0/pci1043,815a@8/disk@0,0
       2. c6t1d0
          /pci@0,0/pci1043,815a@8/disk@1,0
       3. c8t1d0
          /pci@0,0/pci1043,815a@7/disk@1,0
       4. c12t50024E90049E53C0d0
          /scsi_vhci/disk@g50024e90049e53c0
       5. c12t50024E90049E5373d0
          /scsi_vhci/disk@g50024e90049e5373
       6. c12t50024E90049E5393d0
          /scsi_vhci/disk@g50024e90049e5393
       7. c12t50024E90049E5399d0
          /scsi_vhci/disk@g50024e90049e5399
       8. c12t50024E90049E5531d0
          /scsi_vhci/disk@g50024e90049e5531

       9. c12t50024E90049E5533d0
          /scsi_vhci/disk@g50024e90049e5533
Specify disk (enter its number): ^C

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:

root@rk6:~# cd /tank/
root@rk6:/tank#  sync ; time ( dd if=/dev/zero of=test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 254,775 s, 169 MB/s

real    4m22.302s
user    0m0.182s
sys     1m13.054s
root@rk6:/tank#  sync ; time ( dd if=/dev/zero of=test40-2G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 255,2 s, 168 MB/s

real    4m22.170s
user    0m0.185s
sys     1m10.778s
root@rk6:/tank# sync ; time ( dd if=test40G of=/dev/null bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 167,601 s, 256 MB/s

real    2m47.610s
user    0m0.096s
sys     1m9.250s
root@rk6:/tank#  sync ; time ( dd if=test40-2G of=/dev/null bs=1G count=4096 ; sync )
40+0 records in
40+0 records out
42949672960 bytes (43 GB) copied, 160,6 s, 267 MB/s

real    2m41.112s
user    0m0.002s
sys     1m11.027s

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

 

Aloitetaan puhtaalta pöydältä:

root@rk6:~# zpool destroy tank

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

root@rk6:~# for i in c6t0d0 c6t1d0 c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0 ; do sync ; time (dd if=/dev/zero of=/dev/dsk/$i bs=1M count=4096 ; sync ) ; done
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 48,5737 s, 88,4 MB/s

real    0m49.405s
user    0m0.023s
sys     0m14.388s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 50,3224 s, 85,3 MB/s

real    0m51.241s
user    0m0.024s
sys     0m13.862s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 49,0358 s, 87,6 MB/s

real    0m50.002s
user    0m0.025s
sys     0m13.913s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,7972 s, 135 MB/s

real    0m31.818s
user    0m0.020s
sys     0m13.402s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,6148 s, 136 MB/s

real    0m31.636s
user    0m0.025s
sys     0m14.058s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,5836 s, 136 MB/s

real    0m31.605s
user    0m0.021s
sys     0m13.412s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 32,2201 s, 133 MB/s

real    0m32.241s
user    0m0.020s
sys     0m13.261s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,2773 s, 137 MB/s

real    0m31.299s
user    0m0.026s
sys     0m14.236s

4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,4172 s, 137 MB/s

real    0m31.438s
user    0m0.021s
sys     0m13.514s

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

root@rk6:~# for i in c6t0d0 c6t1d0 c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0 ; do dd  if=/dev/dsk/$i of=/dev/null bs=1M count=4096  ; done
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,816 s, 135 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,6488 s, 136 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 31,693 s, 136 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 29,5684 s, 145 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 30,719 s, 140 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 30,6342 s, 140 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 32,1607 s, 134 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 30,6668 s, 140 MB/s
4096+0 records in
4096+0 records out
4294967296 bytes (4,3 GB) copied, 30,7123 s, 140 MB/s

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

zpool create tank c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 96,1818 s, 447 MB/s

real    1m36.980s
user    0m0.187s
sys     1m20.047s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 92,8227 s, 463 MB/s

real    1m33.711s
user    0m0.188s
sys     1m16.480s
root@rk6:~# dd if=/tank/test40G of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 89,9848 s, 477 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 87,7636 s, 489 MB/s

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

root@rk6:~# zpool destroy tank
root@rk6:~# zpool create tank c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 95,2147 s, 451 MB/s

real    1m35.777s
user    0m0.208s
sys     1m17.020s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 95,244 s, 451 MB/s

real    1m35.904s
user    0m0.203s
sys     1m16.810s
root@rk6:~# dd if=/tank/test40G of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 88,8623 s, 483 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 85,859 s, 500 MB/s

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

root@rk6:~# time zpool destroy tank

real    0m1.093s
user    0m0.004s
sys     0m0.096s
root@rk6:~# time zpool create tank c6t0d0 c6t1d0 c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0

real    0m5.160s
user    0m0.164s
sys     0m0.687s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 97,8711 s, 439 MB/s

real    1m38.371s
user    0m0.205s
sys     1m14.232s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 97,4733 s, 441 MB/s

real    1m38.154s
user    0m0.199s
sys     1m14.006s
root@rk6:~# dd if=/tank/test40G of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 89,9894 s, 477 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 87,1675 s, 493 MB/s

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?

root@rk6:~# zpool destroy tank
root@rk6:~# time zpool create tank raidz c6t0d0 c6t1d0 c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0

real    0m5.362s
user    0m0.164s
sys     0m0.677s

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.

root@rk6:~#  sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 196,92 s, 218 MB/s

real    3m17.659s
user    0m0.167s
sys     1m7.422s
root@rk6:~#  sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 198,025 s, 217 MB/s

real    3m18.869s
user    0m0.157s
sys     1m7.614s
root@rk6:~#  dd if=/tank/test40G of=/dev/null bs=1M count=40960

40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 145,183 s, 296 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 140,84 s, 305 MB/s

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

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

real    0m5.292s
user    0m0.165s
sys     0m0.677s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 220,58 s, 195 MB/s

real    3m41.502s
user    0m0.170s
sys     1m10.078s
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 223,302 s, 192 MB/s

real    3m44.439s
user    0m0.179s
sys     1m11.085s
root@rk6:~# dd if=/tank/test40G of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 162,568 s, 264 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 154,673 s, 278 MB/s

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

root@rk6:~# zpool destroy tank
root@rk6:~# zpool create tank raidz3 c6t0d0 c6t1d0 c8t1d0 c12t50024E90049E53C0d0 c12t50024E90049E5373d0 c12t50024E90049E5393d0 c12t50024E90049E5399d0 c12t50024E90049E5531d0 c12t50024E90049E5533d0
root@rk6:~# sync ; time (dd if=/dev/zero of=/tank/test40G bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 272,916 s, 157 MB/s

real    4m34.261s
user    0m0.180s
sys     1m13.341s
root@rk6:~#  sync ; time (dd if=/dev/zero of=/tank/test40G-2 bs=1M count=40960 ; sync )
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 264,459 s, 162 MB/s

real    4m26.056s
user    0m0.180s
sys     1m11.160s
root@rk6:~#  dd if=/tank/test40G of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 158,863 s, 270 MB/s
root@rk6:~# dd if=/tank/test40G-2 of=/dev/null bs=1M count=40960
40960+0 records in
40960+0 records out
42949672960 bytes (43 GB) copied, 152,234 s, 282 MB/s

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:

[root@rk7 Kuvat]# cat /proc/mdstat
Personalities : [raid6] [raid5] [raid4]
md0 : active raid6 sdi[10](S) sdf[0] sdb[9] sdk[8] sdg[7] sdc[6] sdl[5] sde[4] sdd[3] sdh[2] sdj[1]
      15628115968 blocks level 6, 64k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
     
Spare on sdi, mikä levy?

 

[root@rk7 Kuvat]# hdparm -i /dev/sdi

/dev/sdi:

 Model=SAMSUNG HD204UI, FwRev=1AQ10001, SerialNo=S2H7J9EZC06046
…

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

[root@rk7 Kuvat]# hddtemp /dev/sd?
/dev/sda: WDC WD2500JS-00NCB1: 44°C
/dev/sdb: SAMSUNG HD204UI: 29°C
/dev/sdc: Hitachi HDS722020ALA330: 32°C
/dev/sdd: Hitachi HDS722020ALA330: 30°C
/dev/sde: Hitachi HDS722020ALA330: 31°C
/dev/sdf: Hitachi HDS722020ALA330: 31°C
/dev/sdg: WDC WD2001FASS-00W2B0: 40°C
/dev/sdh: Hitachi HDS722020ALA330: 31°C
/dev/sdi: SAMSUNG HD204UI: 36°C
/dev/sdj: SAMSUNG HD204UI: 28°C
/dev/sdk: Hitachi HDS722020ALA330: 39°C
/dev/sdl: Hitachi HDS722020ALA330: 31°C

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