ZFS

[Jouko Holopainen]

Työasemassani:
$ time zx omat.zip
real 0m23.374s
user 0m0.240s
sys 0m0.176s
$ time rm -rf omat
real 0m5.663s
user 0m0.008s
sys 0m0.048s

Tällä välin serverillä jossa IDE boottilevy on vaihdettu SSD:ksi:
~£ pfexec zpool add -f raidpool log c0t1d0s3
~£ pfexec zpool add -f raidpool cache c0t1d0s4

Kokeillaanpa uudestaan:
$ time zx omat.zip
real 0m2.094s
user 0m0.236s
sys 0m0.168s
$ time rm -rf omat
real 0m0.411s
user 0m0.000s
sys 0m0.056s

NFS4 ei ole näämmä se maailman fiksuin järjestelmä. Samaan olisi varmaan
päässyt kun työasemassa olisi pistänyt "async".

Mutta kuinkas sitten kävikään ... kävi niin että yksi kovalevy kuoli.
Sitten kävi niin, että emolevy kuoli. Samalla kuoli uuden $15 SATA-3
ohjainkortin toinen kanava joka rupesi aiheuttamaan CRC virheitä.
Serverikone tilttas täysin, ei edes ssh:lla päässyt sisään. Ensin
vaihdoin virtalähteen, sitten emolevyn, sitten kaikki SATA-kaapelit,
sitten kokeilin Linuxia, yhä CRC virheitä, sitten vaihdoin toiseen
tökkeliin, sitten toimi. Halpa kiinalainen ... (ASM1061). Sitä
virtalähdettä ei mun koneeseen kiinnitetä, vaikka kuka tietää oliko se
syyllinen.

Käytetyt koneet:
Entinen serveri: Asus M3A78 VM + 4G + AMD 5050e
Entinen työasema, nykyinen serveri: ASRock M3A785GM + 4G + AMD 240e
Uusi työasema: Asus F2A85-M LE + 8G + AMD A8-5500
Työasemassa on OCZ-Vertex2 60G, serverissä Samsung 840 EVO 120G.

Voi vittu mikä hulabaloo, 400 ekee paloi hommassa, ton 840:n viemän
satkun lisäksi.

Viestin tärkein sisältö: tässä kaikessa tapahtui 4 CKSUM virhettä ja "no
known data errors". En halua edes kuvitella mitä olisi tapahtunut
jollain lelutiedostojärjestelmällä. Tai miten NAS-purkin kärähtäessä
olisi saanut datat takaisin.

Nykytilanne:
~£ zpool status
pool: raidpool
state: ONLINE
scan: scrub repaired 128K in 7h26m with 0 errors on Thu Oct 24
02:24:05 2013
config:
NAME STATE READ WRITE CKSUM
raidpool ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
c7d1p0 ONLINE 0 0 0
c8d0p0 ONLINE 0 0 0
c7d0p0 ONLINE 0 0 0
c8d1p0 ONLINE 0 0 0
c9d1p0 ONLINE 0 0 0
c9d0p0 ONLINE 0 0 0
logs
c0t1d0s3 ONLINE 0 0 0
cache
c0t1d0s4 ONLINE 0 0 0
errors: No known data errors
pool: rpool1
state: ONLINE
scan: none requested
config:
NAME STATE READ WRITE CKSUM
rpool1 ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0
errors: No known data errors
~£ zpool list
NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT
raidpool 10,9T 5,62T 5,28T - 51% 1.00x ONLINE -
rpool1 29,8G 6,23G 23,5G - 20% 1.00x ONLINE -

Seuraavaksi enabloin LZ4:n ja dedupin, mutta jääkööt joululomalle se.

[Keuvo Makkarainen]

29.10.2013 7:06, Jouko Holopainen kirjoitti:
[klipattu paljon tieskadataa]

Minä ostin Gigantista 999€ tietokoneen. Laitoin siihen +8Gt muistia ja
2*2Tt kiintolevyjä.

Se toimii W7:n avulla kaikkimiten. Voisi serverinäkin käyttää, mutta en
nyt viitsi.

[McJukeH]

Post by Jouko Holopainen
$ time zx omat.zip
real 0m23.374s
user 0m0.240s
sys 0m0.176s
$ time rm -rf omat
real 0m5.663s
user 0m0.008s
sys 0m0.048s
~£ pfexec zpool add -f raidpool log c0t1d0s3
~£ pfexec zpool add -f raidpool cache c0t1d0s4
$ time zx omat.zip
real 0m2.094s
user 0m0.236s
sys 0m0.168s
$ time rm -rf omat
real 0m0.411s
user 0m0.000s
sys 0m0.056s
NFS4 ei ole näämmä se maailman fiksuin järjestelmä. Samaan olisi varmaan
päässyt kun työasemassa olisi pistänyt "async".
Mutta kuinkas sitten kävikään ... kävi niin että yksi kovalevy kuoli.
Sitten kävi niin, että emolevy kuoli. Samalla kuoli uuden $15 SATA-3
ohjainkortin toinen kanava joka rupesi aiheuttamaan CRC virheitä.
Serverikone tilttas täysin, ei edes ssh:lla päässyt sisään. Ensin
vaihdoin virtalähteen, sitten emolevyn, sitten kaikki SATA-kaapelit,
sitten kokeilin Linuxia, yhä CRC virheitä, sitten vaihdoin toiseen
tökkeliin, sitten toimi. Halpa kiinalainen ... (ASM1061). Sitä
virtalähdettä ei mun koneeseen kiinnitetä, vaikka kuka tietää oliko se
syyllinen.
Entinen serveri: Asus M3A78 VM + 4G + AMD 5050e
Entinen työasema, nykyinen serveri: ASRock M3A785GM + 4G + AMD 240e
Uusi työasema: Asus F2A85-M LE + 8G + AMD A8-5500
Työasemassa on OCZ-Vertex2 60G, serverissä Samsung 840 EVO 120G.
Voi vittu mikä hulabaloo, 400 ekee paloi hommassa, ton 840:n viemän
satkun lisäksi.
Viestin tärkein sisältö: tässä kaikessa tapahtui 4 CKSUM virhettä ja "no
known data errors". En halua edes kuvitella mitä olisi tapahtunut
jollain lelutiedostojärjestelmällä. Tai miten NAS-purkin kärähtäessä
olisi saanut datat takaisin.
~£ zpool status
pool: raidpool
state: ONLINE
scan: scrub repaired 128K in 7h26m with 0 errors on Thu Oct 24
02:24:05 2013
NAME STATE READ WRITE CKSUM
raidpool ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
c7d1p0 ONLINE 0 0 0
c8d0p0 ONLINE 0 0 0
c7d0p0 ONLINE 0 0 0
c8d1p0 ONLINE 0 0 0
c9d1p0 ONLINE 0 0 0
c9d0p0 ONLINE 0 0 0
logs
c0t1d0s3 ONLINE 0 0 0
cache
c0t1d0s4 ONLINE 0 0 0
errors: No known data errors
pool: rpool1
state: ONLINE
scan: none requested
NAME STATE READ WRITE CKSUM
rpool1 ONLINE 0 0 0
c0t1d0s0 ONLINE 0 0 0
errors: No known data errors
~£ zpool list
NAME SIZE ALLOC FREE EXPANDSZ CAP DEDUP HEALTH ALTROOT
raidpool 10,9T 5,62T 5,28T - 51% 1.00x ONLINE -
rpool1 29,8G 6,23G 23,5G - 20% 1.00x ONLINE -
Seuraavaksi enabloin LZ4:n ja dedupin, mutta jääkööt joululomalle se.

Voi itku, mutta sinua uskoakseni lieventää tuskaa eräs
karvatassu, joka tulee syliisi, joten elä valita.
Tää on vain elämää.
Ja elämä on!

[Sami Ketola]

Post by Jouko Holopainen
Seuraavaksi enabloin LZ4:n ja dedupin, mutta jääkööt joululomalle se.

Muista sitten että deduppiin tarttet muistia. Nyrkkisäännöllä giga per
tera dedup dataa. Tai ei pakko oo, mutta menee kyllä aika hemmetin
hitaaksi jos DDT ei mahdu muistiin. Tämä siis jos Solaris. Muista
ZFS:ää ajavista ympäristöistä ei oo tietoa.

Sami

[Eino Tuominen]

Post by Sami Ketola
Muista sitten että deduppiin tarttet muistia. Nyrkkisäännöllä giga per
tera dedup dataa. Tai ei pakko oo, mutta menee kyllä aika hemmetin
hitaaksi jos DDT ei mahdu muistiin. Tämä siis jos Solaris. Muista
ZFS:ää ajavista ympäristöistä ei oo tietoa.

Eiköhän tuo päde kaikilla, koska tuo muistintarve tulee juurikin
ZFS:n tavasta tehdä deduplikointi. Ainakin näin annoin itseni
ymmärtää kun joku vuosi sitten tein hiukan "markkinaselvitystä"
aiheesta.

[Jouko Holopainen]

Post by Eino Tuominen

Post by Sami Ketola
Muista sitten että deduppiin tarttet muistia. Nyrkkisäännöllä giga per
tera dedup dataa. Tai ei pakko oo, mutta menee kyllä aika hemmetin
hitaaksi jos DDT ei mahdu muistiin. Tämä siis jos Solaris. Muista
ZFS:ää ajavista ympäristöistä ei oo tietoa.

Eiköhän tuo päde kaikilla, koska tuo muistintarve tulee juurikin
ZFS:n tavasta tehdä deduplikointi. Ainakin näin annoin itseni
ymmärtää kun joku vuosi sitten tein hiukan "markkinaselvitystä"
aiheesta.

Jostain syystä Samin viesti ei näy Saunalahden serverillä ...

Noh, epäilen dedupin hyödyllisyyttä datallani muutenkin ja kun muistia
on vain 4G niin ei siitä jää dedupille yhtään. En viitsisi vaihtaa
kampoja uusiin ja maksaa (taas) satasta, joten: ei sitten.

[Eino Tuominen]

Post by Jouko Holopainen
Noh, epäilen dedupin hyödyllisyyttä datallani muutenkin ja kun muistia
on vain 4G niin ei siitä jää dedupille yhtään. En viitsisi vaihtaa
kampoja uusiin ja maksaa (taas) satasta, joten: ei sitten.

Jos CPU:ta riittää, niin datan pakkausta kannattaa kokeilla, jos
ei kaikki data ole jo valmiiksi pakattua.

En tiedä mihin kuvat ovat täältä hävinneet, mutta silti ihan
mielenkiintoiset tulokset: http://citusdata.com/blog/64-zfs-compression

[Sami Ketola]

Post by Eino Tuominen

Post by Sami Ketola
Muista sitten että deduppiin tarttet muistia. Nyrkkisäännöllä giga per
tera dedup dataa. Tai ei pakko oo, mutta menee kyllä aika hemmetin
hitaaksi jos DDT ei mahdu muistiin. Tämä siis jos Solaris. Muista
ZFS:ää ajavista ympäristöistä ei oo tietoa.

Eiköhän tuo päde kaikilla, koska tuo muistintarve tulee juurikin
ZFS:n tavasta tehdä deduplikointi. Ainakin näin annoin itseni
ymmärtää kun joku vuosi sitten tein hiukan "markkinaselvitystä"
aiheesta.

No ainakin FreeBSD versio tarvitsee enemmän muistia kuin Solaristoteutus.
Jostain syystä FreeBSD:ssä yksi DDT entry on isompi kuin Solariksessa.
Minualla ei ole tietoa miksi.

Sami