ZFS-levyjärjestelmä

[valurauta]

Onko täällä ZFS-levyjärjestelmän kanssa askarrelleita? Tässähän on kyse Sun:in kehittämästä, hienosta ja monipuolisesta levyjärjestelmästä mutta onko siitä harrastekäytössä enemmän vaivaa kuin hyötyä? Miten siitä saa eniten irti ja mihin miinoihin on helppo kompastua? ZFS on nykyään saatavana ilmaiseksi Linuxiin, ZFS on Linux

Parasta ZFS:ssä kai on luotettavuus. Se on harvoja levyjärjestelmiä, joka validoi levyltä luetut tiedot, joten esim. bugaavat levykaapelit paljastuvat. Kaikesta datasta tallennetaan erilliset tarkistussummat, jotka tarkistetaan dataa luettaessa. Luotettavuutta voi edelleen parantaa datan monistamisella (esim. tiedostojärjestelmälle voi kertoa, että kaikki data tallennetaan kahteen eri paikkaan). Toisaalta ZFS tukee pakkaamista ja deduplikaatiota (ZFS tunnistaa jos riippumattomissakin tiedostoissa on yhteneviä datajaksoja ja säilöö datan vain yhteen kertaan). Lokia muutoksista voi pitää snapshoteilla.

Kaikki tämä ei tule ihan ilmaiseksi, joten ZFS ei ole maailman nopein tiedostojärjestemä. Etenkin deduplikaatio vaatii roimasti muistia ja vääntöä kirjoitettaessa.

Infraa ZFS:ssä riittää isoihinkin palvelimiin mutta maksaako vaivaa ottaa ZFS:ää käyttöön koti/harrastekäytössä? ZFS kai osaa tehdä RAID-toimintojakin mutta se ei mitenkään välttämättä ole RAID. Päinvastoin, oletusarvoisesti jos ZFS:ään lisää useita levyjä, yhdenkin rikkoutuminen rikkoo myös ZFS:n ja kaikkea dataa tuskin saa pelastettua.

 

[Jerzy]

Vai viittaako valurauta tilanteeseen jossa vanhan vdevin rinnalle on tehty uusi vdev jossa vain yksi levy, jos kuvan vdev2 kosahtaa, niin koko pooli hajoaa?

 

[valurauta]

Vai viittaako valurauta tilanteeseen jossa vanhan vdevin rinnalle on tehty uusi vdev jossa vain yksi levy, jos kuvan vdev2 kosahtaa, niin koko pooli hajoaa?

Itse asiassa kai juuri tämä. Zpooliin kun menee huolimattomasti lisäämään uuden levyn se, ei oletusarvoisesti tule miksikään "RAID-levyksi" tai osaksi olemassa olevaa pakkaa vaan zpool vain laajenee kattamaan kaikki levyt. Tai no, RAID:han se RAID-0:kin on, mutta... Todellinen miina on siinä, että väärin lisättyä levyä ei enää saa mitenkään irti tai koko zpool menee rikki.

 

[samim]

Onko täällä ZFS-levyjärjestelmän kanssa askarrelleita? ZFS kai osaa tehdä RAID-toimintojakin mutta se ei mitenkään välttämättä ole RAID. Päinvastoin, oletusarvoisesti jos ZFS:ään lisää useita levyjä, yhdenkin rikkoutuminen rikkoo myös ZFS:n ja kaikkea dataa tuskin saa pelastettua.

Ihan samoin käy, kun teet itsellesi RAID-0 levyn, yhden levyn hajoaminen hävittää datan. ZFS:n taisi saada sekä three-way-mirrorina että pystyit tekemään filesysteemitasolla määrityksen, montako kopiota datasta pidetään. Jerzyn kuva kertoo just, kun ei osata konffia tuota.

Vilkaise FreeNAS:n sivuja ja sen suosiota.

Jos Oracle olis tajunnut jättää tämän Opensourceksi ja jatkanut sen kehityämistä opensourcena, niin tämä olisi nyt joka Linuxin default levynhallintajärjestelmä. Itse epäilen, että MS kopioi vähintäänkin idean tästä Storage spacesiin, mutta toteutti sen jälleen kerran vajavaisesti.

 

[valurauta]

Ihan samoin käy, kun teet itsellesi RAID-0 levyn, yhden levyn hajoaminen hävittää datan. ZFS:n taisi saada sekä three-way-mirrorina että pystyit tekemään filesysteemitasolla määrityksen, montako kopiota datasta pidetään. Jerzyn kuva kertoo just, kun ei osata konffia tuota.

Vilkaise FreeNAS:n sivuja ja sen suosiota.

RAID-0:n tekeminen lienee useimmiten tietoinen valinta. ZFS:n konfiguraatio on vähän turhan helppo ryssiä ("otanpa tuon vanhan rohjakkeen tilapäiseksi lisätilaksi...", tjsp), ja laajennuskomennolle ei ole Undo:a. Kun tekee erillisen zpoolin, ei tule ongelmaa.

Yksi ZFS:n mainio ominaisuus on tuki SSD-cachelle, mikä voi nopeuttaa lukutoimintoja ajan mittaan ihan kivasti.

 

[samim]

Se on tuon zfs:n ominaisuus, että poolin rakennetta ei voi/eikä saa muuttaa. Ainoa tapa on vaihtaa levy toiseen samankokoiseen tai isompaan, ja jälkimmäisessa vaihtoehdossa lisäys joko saadaan tai ei saada käyttöön. Jos pooliin meinaa lisätä toisen vdevin, niin oletusarvoisesti hommat ollaan ryssimässä.

 

[Fenotype]

Lisää suden kuoppia joihin voi pudota.
Liian vähän ram muistia, cacheilla väärin kikkailu, zfs metadatan paskominen, poolin "unmounttaus" ja samalla vahingossa ruksi kohtaan uudista zfs pooli.

Sähkökatkos on monilla saanut zfs metadatan paskiksi.
Itse en ole onnistunut sähkökatkolla saamaan zfs poolia paskaksi.

 

[spede]

Täällä kanssa tapahtunut varmaan 10+ sähkökatkosta noiden parin vuoden aikana, kun on zpool pyörinyt 24/7 levypalvelimessa eikä mitään ongelmia niiden johdosta.

Suurin ongelma on raidz moodien kankeus ja nihkeä päivitettävyys. Jos dataa tulee joku <1TB vuodessa lisää, niin koko raidz:n levyjen päivittäminen suuremmiksi lisätilan saamiseksi on vähän turhan kallis operaatio. Tästä syystä lähtee todennäköisesti seuraavan NAS:n päivityksen yhteydessä ZFS vaihtoon ja tilalle joku snapraid tms.

Jos raidiin voisi lisätä levyn kerrallaan ja antaa resilver komennon poolille, niin jäisi kyllä käyttöön. Vissiin btrfs:n kanssa onnistuu, mutta taitaa ko. tiedostojärjestelmä olla vielä melkoisen raakile.

 

[valurauta]

Jos raidiin voisi lisätä levyn kerrallaan ja antaa resilver komennon poolille, niin jäisi kyllä käyttöön.

Jos kolmen levyn pakkaan lisää neljännen, koko pakan kaikki data ja pariteetti-info kai on luettava ja kirjoitettava uudelleen?

Semmoistakin olen kuullut, että Raid-pakan resilver-toiminto saattaa olla viimeinen niitti pakan vanhemmille levyille. Kun levyjen koko on nykyään mitä on, pakan korjaaminen ei ole mikään kevyt eikä nopea operaatio ja se voi olla liian kova rasitus vähänkään vajaakuntoisille levyille.
Jos pakasta hajoaa levy resilverin aikana ... ovathan varmuuskopiot aina kunnossa, ovathan?

 

[samim]

Jos kolmen levyn pakkaan lisää neljännen, koko pakan kaikki data ja pariteetti-info kai on luettava ja kirjoitettava uudelleen?

Tuo vaan ei zfs:ssä onnistu. Jos sulla on yksi pooli, jossa on yksi vdev, ja tuossa vdevissä on jo kolme diskiä, niin neljännen saat siihen _vain_ rikkomalla poolin ja tekemällä sen uudelleen. Luonnollisesti kaikki data hävis.

 

[samim]

Toinen vaihtoehto on lisätä pooliin uusi vdev. Jos lisäät yhden levyn vdevin, niin tilanne on sama, kun laajentaisit raidia lisäämällä sen loppuun alueen, jossa ei ole mitää suojaa, vain yhden levyn kapasiteetti lisää.

Oikea tapa olisi lisätä vdev, jossa kolme levyä, niin kuin ekassakin vdevissä.

 

[spede]

Tuo vaan ei zfs:ssä onnistu. Jos sulla on yksi pooli, jossa on yksi vdev, ja tuossa vdevissä on jo kolme diskiä, niin neljännen saat siihen _vain_ rikkomalla poolin ja tekemällä sen uudelleen. Luonnollisesti kaikki data hävis.

Juuri näin, eli jos on vaikka 3x6TB raidz1 vdev niin tuon yhden levyn lisäämisen ajaksi olisi pieraistava jostain muualta 12TB tilaa siksi aikaa. Tästä syystä itse en todennäköisesti jatka ZFS:n käyttöä. Toki oma käyttötarkoitus ei muutenkaan huuda mitään enterprise ratkaisua.

Esimerkiksi SUSE:ssa Btrfs on ollut oletustiedostojärjestelmänä jo jonkun aikaa. Uskoisin kuitenkin, että de facto standardi Btrfs:stä tulee vasta sitten kun Red Hat siirtyy siihen omissa tuotteissaan.

Ilmeisesti kehitystä on sitten tapahtunut jo hyvin.

 

[Mechanical Man]

Juuri näin, eli jos on vaikka 3x6TB raidz1 vdev niin tuon yhden levyn lisäämisen ajaksi olisi pieraistava jostain muualta 12TB tilaa siksi aikaa. Tästä syystä itse en todennäköisesti jatka ZFS:n käyttöä. Toki oma käyttötarkoitus ei muutenkaan huuda mitään enterprise ratkaisua.

...

Käsittääkseni onnistuu kasvattaminen siten, että vaihtaa yhden levyn kerrallaa, rebuildaa raidz:n välissä ja kun kaikki on vaihdettu, kasvaa koko.

Toki tuokin on ihan annelista tehdä. Siksi itsellä onkin kaksi 3:n levyn raidz1 poolia, päivitän aina pienemmän isommaksi kun tila loppuu, niin aina on tilaa päivitellä.

 

[dataaja95]

Olisi tarkoitus siirtyä virtualisointiympäristössä käyttämään zfs. Vaikuttaa muuten oikein pätevältä tiedostojärjestelmältä mutta ongelmana on tuo levyjen lisääminen. Et siis voi lisätä yhtä levyä zfs pooliin rikkomatta koko poolia. Olenko oikein ymmärtänyt. Olisiko vastaavia zfs:n kaltaisia tiedostojärjestelmiä mihin voi lisätä yksittäisiä levyjä ilman systeemin hajoamista. Olenko oikeassa että ainoa tapa lisätä yksittäisiä levyjä zfs:ään on luoda toinen pooli ja lisätä levy siihen. Ei kuulosta kauhean toimivalta.

 

[dataaja95]

Tietenkin on btrfs mutta onko se riittävän vakaa käyttöön käytettäessä esim raid6

 

[samim]

Olisi tarkoitus siirtyä virtualisointiympäristössä käyttämään zfs. Vaikuttaa muuten oikein pätevältä tiedostojärjestelmältä mutta ongelmana on tuo levyjen lisääminen. Et siis voi lisätä yhtä levyä zfs pooliin rikkomatta koko poolia.

Et maininnut, mikä käyttis on kyseessä, mutta lähtökohtaisesti olet ymmärtänyt oikein.

Katso tuota linkin dokua: Adding Devices to a Storage Pool - Managing ZFS File Systems in Oracle® Solaris 11.3

Pool on kuin mikä tahansa iso vituaalilevy. ZFS:ssä se voi koostua mirror, raidz1 tai raidz2 -deviceistä, jotka sitten luodaan fyysisistä levyistä. Eli voit kasvattaa poolia minimissään mirror-devicellä, jossa on kaksi levyä data peilattuna.

Tai raidz1-devicellä, jossa data on vähintään kolmella levyllä niin, että yhden hajoamisesta selvitään. Raidz2 taisi olla min neljä levyä, joista kaksi voi hajota.

Poolin rakennetta voi muuttaa myös vaihtamalla olemassaolevat levyt isompiin yksi kerrallaan. Lisää levytilaa tosin tulee vasta, kun mirror, raid1z tai raid2z-kokonaisuus on kokonaan kasvatettu isommaksi.

Isoin töppäys tulee adminille, joka lisää pooliin yhden levyn olemassaolevan kokonaisuuden jatkeeksi. Levytila kasvaa, mutta jos tuo lisätty levy hajoaa, niin game over.

 

[dataaja95]

Et maininnut, mikä käyttis on kyseessä, mutta lähtökohtaisesti olet ymmärtänyt oikein.

Katso tuota linkin dokua: Adding Devices to a Storage Pool - Managing ZFS File Systems in Oracle® Solaris 11.3

Pool on kuin mikä tahansa iso vituaalilevy. ZFS:ssä se voi koostua mirror, raidz1 tai raidz2 -deviceistä, jotka sitten luodaan fyysisistä levyistä. Eli voit kasvattaa poolia minimissään mirror-devicellä, jossa on kaksi levyä data peilattuna.

Tai raidz1-devicellä, jossa data on vähintään kolmella levyllä niin, että yhden hajoamisesta selvitään. Raidz2 taisi olla min neljä levyä, joista kaksi voi hajota.

Poolin rakennetta voi muuttaa myös vaihtamalla olemassaolevat levyt isompiin yksi kerrallaan. Lisää levytilaa tosin tulee vasta, kun mirror, raid1z tai raid2z-kokonaisuus on kokonaan kasvatettu isommaksi.

Isoin töppäys tulee adminille, joka lisää pooliin yhden levyn olemassaolevan kokonaisuuden jatkeeksi. Levytila kasvaa, mutta jos tuo lisätty levy hajoaa, niin game over.

Tosiaan käyttiksenä on proxmox. Käytännössä debianin päälle kasattu virtualisointiympäristö omalla kernelillään
Proxmox - powerful open-source server solutions

 

[spede]

En lähtisi millään kovin tärkeällä datalla ajelemaan btrfs levyjärjestelmää RAID5/6 tasoilla, vaikka ilmeisesti tuokin toimii ihan jees. Enterprise tasolla 5 ja 6 RAID on kuoleva laji, koska lukuvirheen todennäköisyys isoilla levyilla nousee liian suureksi. Kaikki uudet järjestelmät käyttänevät RAID 10. Tästä syystä varmaan ei ole ollut mitään kiirettä rassata tuotakaan ihan niin toimivaksi, että katsastajan leiman saisi.

Jos joustavuutta tarvitsee, niin SnapRAID-järjestelmään saa 1-6 pariteettilevyä, voi lisätä yksittäisiä levyjä milloin haluaa ja levyt voivat olla eri kokoisia, värisiä ja vaikka eri tiedostojärjestelmällä.

Vähän käyttökohteesta riippuu, että mitä kannattaisi tehdä. Jos jotain virtuaalikoneita tarkoitus pyörittää, niin ZFS on siihen aika lyömätön ratkaisu. Jos taas säilötään jotain mediatiedostoja tms. kirjoita kerran ja lue silloin tällöin -settiä, niin SnapRAID on hyvä.

 

[peksi]

Btrfs suunniteltiin juuri tuota joustavuutta silmällä pitäen. Btrfs on muuten vakaa lukuunottamatta RAID 5/6 -tasoja, eli esim RAID 10 toimii ihan hyvin. Esimerkiksi SUSE:ssa Btrfs on ollut oletustiedostojärjestelmänä jo jonkun aikaa. Uskoisin kuitenkin, että de facto standardi Btrfs:stä tulee vasta sitten kun Red Hat siirtyy siihen omissa tuotteissaan.

Btrfs:n raid5/6 tosiaan paljastui vähän ongelmalliseksi, noin vuosi sitten esim: Btrfs RAID 5/6 Code Found To Be Very Unsafe & Will Likely Require A Rewrite - Phoronix eivätkä vieläkään suosittele: RAID56 - btrfs Wiki

The parity RAID code has multiple serious data-loss bugs in it. It should not be used for anything other than testing purposes.

Koko btrfs saattaa osoittautua umpikujaksi. Sitä on kehitetty kohta kymmenen vuotta ja vieläkin osa ominaisuuksista puuttuu ja perusjuttujen kanssa on ongelmia esim. itse kohtasin melkosia perffiongelmia kuormien alla joista ZFS selviytyi ihan kivasti. Tiedostojärjestelmien kehitys ei toki ole mitään hätäisen hommaa mutta ZFS:kin oli tuotannossa paljon nopeammin.

Red Hat on menettänyt jo toivonsa btrfs:n suhteen deprekoiden sen ensin jakelustaan ja panostamalla sitten Stratisiin: Stratis Is Red Hat's Plan For Next-Gen Linux Storage Without Btrfs - Phoronix Tuon designdokkarista:

ZFS isn’t an option RHEL can embrace due to licensing (Ubuntu notwithstanding.) Btrfs has no licensing issues, but after many years of work it still has significant technical issues that may never be resolved.

 

[spede]

Red Hat on menettänyt jo toivonsa btrfs:n suhteen deprekoiden sen ensin jakelustaan ja panostamalla sitten Stratisiin: Stratis Is Red Hat's Plan For Next-Gen Linux Storage Without Btrfs - Phoronix

(Copying and pasting my response from hackernews)

People are making a bigger deal of this than it is. Since I left Red Hat in 2012 there hasn't been another engineer to pick up the work, and it is a lot of work.

For RHEL you are stuck on one kernel for an entire release. Every fix has to be backported from upstream, and the further from upstream you get the harder it is to do that work.

Btrfs has to be rebased every release. If moves too fast and there is so much work being done that you can't just cherry pick individual fixes. This makes it a huge pain in the ass.

Then you have RHEL's "if we ship it we support it" mantra. Every release you have something that is more Frankenstein-y than it was before, and you run more of a risk of shit going horribly wrong. That's a huge liability for an engineering team that has 0 upstream btrfs contributors.

The entire local file system group are xfs developers. Nobody has done serious btrfs work at Red Hat since I left (with a slight exception with Zach Brown for a little while.) Suse uses it as their default and has a lot of inhouse expertise. We use it in a variety of ways inside Facebook. It's getting faster and more stable, admittedly slower than I'd like, but we are getting there. This announcement from Red Hat is purely a reflection of Red Hat's engineering expertise and the way they ship kernels, and not an indictment of Btrfs itself.

 

[peksi]

Joo, oli tiedossa että tossa RH:n deprekointipäätöksessä oli kyse lähinnä siitä etteivät näe enää tarpeelliseksi palkata tyyppiä rebasettamaan Btrfs:n muutoksia RHELin legacykerneliin mutta signaali on päivänselvä yhä kuten tuossa Stratis-dokkarissakin mainitsevat.

 

[greenlight]

Kyse on vain siitä, että Red Hat tarvitsee tietynlaista teknologiaa liiketoimintansa pyörittämiseen ja btrfs ei sitä tarjoa juuri nyt. Red Hatin päätös on vaivoin mikään signaali, sillä firma ei ole aiemminkaan osallistunut btrfs:n kehittämiseen, joten tässä ei olla vetämässä mattoa kenenkään jalkojen alta.

 

[peksi]

Kyse on vain siitä, että Red Hat tarvitsee tietynlaista teknologiaa liiketoimintansa pyörittämiseen ja btrfs ei sitä tarjoa juuri nyt. Red Hatin päätös on vaivoin mikään signaali, sillä firma ei ole aiemminkaan osallistunut btrfs:n kehittämiseen, joten tässä ei olla vetämässä mattoa kenenkään jalkojen alta.

No jos he olemassaolevaan Btrfs:ään panostamisen sijaan päättävät alottaa uusiksi tutumman teknologian kanssa ja toteavat tämän whitepaperissa suoraan Btrfs:n olevan ongelmallinen niin aika selvä IMO.

Red Hatilla siis oli ennen ihan fs-kehittäjiä commitoimassa Btrfs:ään suoraan mutta nykyään tätä ei nähdä tarpeellisena. Ei Btrfs toki mainlinesta ole mihinkään lähdössä mutta vähän epätoivoiselta vaikuttaa. Pitkän kehityskaaren jälkeen melko surullinen tilanne, ei viitsi ihan hirveästi missään vakavassa tuotannossa käyttää ellei satu olemaan iskuryhmä fs:n kehittäjiä debuggaamassa ja korjaamassa vieressä (kuten Facebookilla) Status - btrfs Wiki

Sitä nimenomaan haluaisi jonkun fiksun modernin COW-systeemin Linuxille ja vielä ilman mitään out-of-tree kikkailuja mitä ZFS vaatii mutta vuosi toisensa jälkeen Btrfs:n kanssa on ollut vain ongelmia.

 

[greenlight]

Red Hatilla siis oli ennen ihan fs-kehittäjiä commitoimassa Btrfs:ään suoraan mutta nykyään tätä ei nähdä tarpeellisena.

Nettikeskustelun perusteella heillä oli yksi itsenäinen kehittäjä, joka työskenteli btrfs:n parissa, ja sitten vaihtoi työpaikkaa. Tiedä vaikka idea btrfs:n käyttämisestä olisi ollut seurausta kyseisen kehittäjän lobbaustyöstä tms.

Pitkän kehityskaaren jälkeen melko surullinen tilanne, ei viitsi ihan hirveästi missään vakavassa tuotannossa käyttää ellei satu olemaan iskuryhmä fs:n kehittäjiä debuggaamassa ja korjaamassa vieressä (kuten Facebookilla) Status - btrfs Wiki

Tilannehan on ollut tämä aina ja sen takia btrfs ei ole yleistynyt vaan on jämähtänyt Facebookin ja Susen sisäpiirin jutuksi. Silloin on syytä alkaa huolestua, jos nämä tahot alkavat katsella btrfs:n sijaan muita vaihtoehtoja.

 

[peksi]

Nettikeskustelun perusteella heillä oli yksi itsenäinen kehittäjä, joka työskenteli btrfs:n parissa, ja sitten vaihtoi työpaikkaa. Tiedä vaikka idea btrfs:n käyttämisestä olisi ollut seurausta kyseisen kehittäjän lobbaustyöstä tms.

Tuskin yhden ihmisen takia perusteella ovat hehkuttaneet Btrfs:ää aiemmin: nopealla git-magiikalla 14 ihmistä Red Hatilta on commitoinut btrfs:ään kernelissä muutaman vuoden sisään (en jaksa tarkistaa moniko on ollut tekemässä isompia remontteja)

Fedorassakin oli pakettimanagerissa kätevä Btrfs-tuki ja puhuivat aikanaan miten "seuraavassa versiossa" Fedorassa on Btrfs oletuksena ja sen jälkeen RHELissä. Suunta tiedostojärjestelmien osalta vaikutti silloin ihan selvältä mutta sittemmin on tullut täyskäännös.

Tilannehan on ollut tämä aina ja sen takia btrfs ei ole yleistynyt vaan on jämähtänyt Facebookin ja Susen sisäpiirin jutuksi. Silloin on syytä alkaa huolestua, jos nämä tahot alkavat katsella btrfs:n sijaan muita vaihtoehtoja.

No nimenomaan todella huolestuttavaa jos kohta FS:ää on kohta kehitetty kymmenen vuotta ja edelleen löytyy pariteettiraidista design flaw ja wikissä featuren toisensa jälkeen "toimii...MUTTA" -tason selitystä eikä uskalleta käyttää tuotannossa.

 

[dataaja95]

Nyt pyörii sitten zfs proxmoxissa raiz:lla Käytössä 4 levyä ja tilaa poolissa noin 500gt. Juuri siirretään virtuaalikoneita zfs pakalle varmuuskopiosta. On tuo kyllä pirun nopea. Lisää levytilaa hankitaan tarpeen mukaan. Mutta jos tuo kerta noin hyvin toimii. Ei poolin uudelleen rakentaminen ja backupeista virtuaalikoneiden siirtäminen ole mikään kauhea homma.
root@pve:~# zpool status
pool: virtualisointi
state: ONLINE
scan: none requested
config:

NAME STATE READ WRITE CKSUM
virtualisointi ONLINE 0 0 0
raidz1-0 ONLINE 0 0 0
sda ONLINE 0 0 0
sdb ONLINE 0 0 0
sdc ONLINE 0 0 0
sde ONLINE 0 0 0

errors: No known data errors
root@pve:~#

 

[spede]

Jos ZFS lisensointi saatettaisiin jollain ilveellä kuntoon Oraakkelin toimesta ja siihen sorvattaisiin tuki levyn lisäämiselle vdev:iin + rebalance niin eipä tarvitsisi miettiä mitä levyjärjestelmää käyttää.

 

[dataaja95]

Jos ZFS lisensointi saatettaisiin jollain ilveellä kuntoon Oraakkelin toimesta ja siihen sorvattaisiin tuki levyn lisäämiselle vdev:iin + rebalance niin eipä tarvitsisi miettiä mitä levyjärjestelmää käyttää.

Kai tuosta jonnekkin kehitysehdotuksen voi heittää. EN usko että olet ainoa kuka sen levynlisäämisen haluaisi zfs:ään. Olisi kyllä kova juttu.

 

[Pertti Kosunen]

Redhat siirtyy Pötteringin suunnittelemaan uuteen integroituun SystemDFS:iin. Tuo tulee samalla pakolliseksi root tiedostojärjestelmäksi.

 

[Grazer]

Itseltä laukesi ZFS:n mirror-pakasta (2x3TB) toinen levy ja kun vaihdoin tuon uuteen, niin resilver tapahtuu kovin hitaasti. Nopeus sellaista 10Mt/s. Onko jossain tweakattavaa vai mistä moinen mahtaisi johtua? Ashift on 12, eli siitä ei hirtä kiinni. Palvelin ilmoittaa arvioiduksi resilver-ajaksi tuolla ~65 tuntia. CPU-kuormaa ei ainakaan aiheuta, melkein idlenä lotkottelee. Koneen Microserver N54L, muistia 16 gigaa.

Edellinen levyrikko tapahtui vanhempien serverissä, jossa pyörii 3x2TB RAID5-pakka Mdraidilla ja ei tuon ehjäämiseen mennyt kuin ~8-10h, referenssiksi tämä.

EDIT: Ei taaskaan saanut halvalla hyvää. Tuo hajonnut levy (bad sectoreita paljon) on noita verkkiksen myymiä Verbatimeja. Tämä on mallia Toshiba DT01ACA300.

 

[Pertti Kosunen]

Mikä käyttöjärjestelmä?

 

[Grazer]

Ubuntu 14.04

 

[Fenotype]

Mikä on normi scrub aika tolle mirror poolilles?

 

[Grazer]

Tuon poolin scrub-aikaa en muista (en tiedä, löytyisikö tuo jostain lokista), mutta koneessa pyörii myös 3x1-terainen raidz1-pakka ja siinä scrub kestänyt viimeksi 5h 23 min. Dataa pooleissa jotakuinkin yhtä paljon (pari teraa, eli raidz1 melkein täynnä, mirror 2/3).

 

[Fenotype]

Kuulostaa hieman alhaiselta i/o nopeudelta (ihan normia halpa boxille). Joku joskus oli i/o ta nopeuttanut LSI 9211-8i kortilla hp microserverissä.
Itsellä AMD FX koneessa raidz2 6x3tb 84% full poolissa scrub ajat oli jotain 2,1h.
Jos olisit sanonut että normi scrub on 30min, niin sitten olisin ollut aika huolestunut, että lisää kovoja menossa rikki.

Edit:varmaan kyllä kantsii resilverin jälkeen tarkastaa kovojen kunto, vaikkakin oletan että backupit on kunnossa kun kerran mirroria käytät.

 

[Pertti Kosunen]

Ubuntu 14.04

Very slow scrub in Ubuntu 16.04 · Issue #4627 · zfsonlinux/zfs

Onko tuo zfs_resilver_delay jo nollassa?

 

[Grazer]

Very slow scrub in Ubuntu 16.04 · Issue #4627 · zfsonlinux/zfs

Onko tuo zfs_resilver_delay jo nollassa?

Kakkosessa. Lennosta tuon muuttaminen ei ainakaan vaikuttanut.

 

[samim]

Kannattaa antaa mennä vaan läpi ilman isompia säätöä. Jos vaikka se toinen levy on menossa heikompaan suuntaan, ja siksi sen IO on vähän heikolla hapella.

 

[Fenotype]

Vieläkö @Grazer rin ubuntu ruksuttaa?

 

[Grazer]

Meni läpi:
"scan: resilvered 2.01T in 65h41m with 0 errors on Thu Apr 19 10:33:07 2018"

Ajoin tuon jälkeen scrubin:
"scan: scrub repaired 0 in 5h21m with 0 errors on Thu Apr 19 22:02:02 2018"

 

[Fenotype]

Ookko smartteja seurannu?
smartctl -a /dev/sda0 (vai miten se linuxissa menee)

 

[Grazer]

Olen.
Ehjän levyn (Toshiba DT01ACA300) tiedot.

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   139   139   054    Pre-fail  Offline      -       71
  3 Spin_Up_Time            0x0007   152   152   024    Pre-fail  Always       -       420 (Average 334)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       11
  5 Reallocated_Sector_Ct   0x0033   100   100   005    Pre-fail  Always       -       0
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   124   124   020    Pre-fail  Offline      -       33
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       21530
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       11
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       294
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       294
194 Temperature_Celsius     0x0002   166   166   000    Old_age   Always       -       36 (Min/Max 23/41)
196 Reallocated_Event_Count 0x0032   100   100   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

Pakasta pois potkittu levy on testikoneessa nyt, haen smartit siitäkin

EDIT: Pakasta pudonnut levy. Saman mallin Toshiba kuin ylempänä

ID# ATTRIBUTE_NAME          FLAG     VALUE WORST THRESH TYPE      UPDATED  WHEN_FAILED RAW_VALUE
  1 Raw_Read_Error_Rate     0x000b   100   100   016    Pre-fail  Always       -       0
  2 Throughput_Performance  0x0005   080   080   054    Pre-fail  Offline      -       1201
  3 Spin_Up_Time            0x0007   132   132   024    Pre-fail  Always       -       438 (Average 433)
  4 Start_Stop_Count        0x0012   100   100   000    Old_age   Always       -       20
  5 Reallocated_Sector_Ct   0x0033   001   001   005    Pre-fail  Always   FAILING_NOW 1400
  7 Seek_Error_Rate         0x000b   100   100   067    Pre-fail  Always       -       0
  8 Seek_Time_Performance   0x0005   124   124   020    Pre-fail  Offline      -       33
  9 Power_On_Hours          0x0012   097   097   000    Old_age   Always       -       21356
 10 Spin_Retry_Count        0x0013   100   100   060    Pre-fail  Always       -       0
 12 Power_Cycle_Count       0x0032   100   100   000    Old_age   Always       -       20
192 Power-Off_Retract_Count 0x0032   100   100   000    Old_age   Always       -       240
193 Load_Cycle_Count        0x0012   100   100   000    Old_age   Always       -       240
194 Temperature_Celsius     0x0002   222   222   000    Old_age   Always       -       27 (Min/Max 24/44)
196 Reallocated_Event_Count 0x0032   001   001   000    Old_age   Always       -       10727
197 Current_Pending_Sector  0x0022   100   100   000    Old_age   Always       -       48
198 Offline_Uncorrectable   0x0008   100   100   000    Old_age   Offline      -       0
199 UDMA_CRC_Error_Count    0x000a   200   200   000    Old_age   Always       -       0

 

[Fenotype]

offtopic:12.5.2018
omaan serveriin on nyt keväällä putkahtanut huonoja sektoreita

Spoileri: code

=== START OF INFORMATION SECTION ===
Model Family:     Seagate Barracuda 7200.11
Device Model:     ST31500341AS
Serial Number: 
LU WWN Device Id:
Firmware Version: CC1H
User Capacity:    1,500,301,910,016 bytes [1.50 TB]
Sector Size:      512 bytes logical/physical
Rotation Rate:    7200 rpm
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 2.6, 3.0 Gb/s
Local Time is:    Sat May 12 15:28:26 2018 EEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
ada0
  5 Reallocated_Sector_Ct   0x0033   099   099   036    Pre-fail  Always       -       77
ada1
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       23
ada2
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       3
ada3
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       0
ada4
  5 Reallocated_Sector_Ct   0x0033   100   100   036    Pre-fail  Always       -       36
ada5
  5 Reallocated_Sector_Ct   0x0033   097   097   036    Pre-fail  Always       -       124

 

[RHead]

Mitähän ihmettä tapahtu proxmoxissa, kun boottas upgraden jälkeen niin mitää ei näy enää mountti kansioissa??

zfs kyllä näyttää että dataa siellä ois:

NAME                           USED  AVAIL  REFER  MOUNTPOINT
data                          2.19T  3.00T   199K  /data
data/image                     170K  3.00T   170K  /data/image
data/iso                      6.45G  3.00T  6.45G  /data/iso
data/store                    2.18T  3.00T   199K  /data/store
data/store/subvol-100-disk-0  2.18T  2.70T  2.18T  /data/store/subvol-100-disk-0
data/subvol-100-disk-0         863M  7.16G   863M  /data/subvol-100-disk-0
vm                            98.1G   117G   333M  /vm
vm/vm-101-disk-0              23.5G   136G  2.85G  -
vm/vm-102-disk-0              74.3G   135G  56.4G  -

mutta jos käy tuolla /data kansiossa löytyy vain:

root@pve:/data# ls -R
.:
image  iso  store  subvol-100-disk-0

./image:

./iso:
dump  images  template

./iso/dump:

./iso/images:

./iso/template:
cache  iso

./iso/template/cache:
debian-9-turnkey-fileserver_15.0-1_amd64.tar.gz

./iso/template/iso:

./store:
subvol-100-disk-0

./store/subvol-100-disk-0:

./subvol-100-disk-0:
dev  store

./subvol-100-disk-0/dev:

./subvol-100-disk-0/store:
root@pve:/data#

 

[muumio]

Kannattaa lisätä nuo tulosteet suoraan koodi tagien sisään niin ei web kikkareet raiskaa tulostetta niin on huomattavasti mukavempi lukea.

Onhan purkki bootattu vastaavan version moduleilla ettei ole vanhalla versiolla?

Omassa purkissa jostain syystä 0.8.1 sekoilee niin, että jos ei initramfs ole sisällytetty zfs kikkareita niin ei löydä pooleja lainkaan vaikka zfs on vain ja ainoastaan data-levyillä käytössä.

 

[RHead]

Kannattaa lisätä nuo tulosteet suoraan koodi tagien sisään niin ei web kikkareet raiskaa tulostetta niin on huomattavasti mukavempi lukea.

Onhan purkki bootattu vastaavan version moduleilla ettei ole vanhalla versiolla?

Omassa purkissa jostain syystä 0.8.1 sekoilee niin, että jos ei initramfs ole sisällytetty zfs kikkareita niin ei löydä pooleja lainkaan vaikka zfs on vain ja ainoastaan data-levyillä käytössä.

Korjattu koodi.

Joo buutattu laite useasti eikä auta.

 

[muumio]

Hassua kun pikasella googlella esiin tulee heti proxmox vaikkei hakusanaan edes laita sitä

Mitä zfs get mountpoint ja zfs get mounted tulostaa?

 

[RHead]

root@pve:/mnt# zfs get mountpoint
NAME                          PROPERTY    VALUE                          SOURCE
data                          mountpoint  /data                          default
data/image                    mountpoint  /data/image                    default
data/iso                      mountpoint  /data/iso                      default
data/store                    mountpoint  /data/store                    default
data/store/subvol-100-disk-0  mountpoint  /data/store/subvol-100-disk-0  default
data/subvol-100-disk-0        mountpoint  /data/subvol-100-disk-0        default
vm                            mountpoint  /vm                            default
vm/vm-101-disk-0              mountpoint  -                              -
vm/vm-101-disk-0@buutti       mountpoint  -                              -
vm/vm-102-disk-0              mountpoint  -                              -
root@pve:/mnt# zfs get mounted
NAME                          PROPERTY  VALUE    SOURCE
data                          mounted   no       -
data/image                    mounted   no       -
data/iso                      mounted   no       -
data/store                    mounted   no       -
data/store/subvol-100-disk-0  mounted   no       -
data/subvol-100-disk-0        mounted   no       -
vm                            mounted   yes      -
vm/vm-101-disk-0              mounted   -        -
vm/vm-101-disk-0@buutti       mounted   -        -
vm/vm-102-disk-0              mounted   -        -
root@pve:/mnt#

 

[muumio]

Herjaako zfs mount -a jotain vai lähteekö sillä pelittämään?

 

[RHead]

root@pve:/mnt# zfs mount -a
cannot mount '/data': directory is not empty
cannot mount '/data/iso': directory is not empty
cannot mount '/data/store': directory is not empty
cannot mount '/data/subvol-100-disk-0': directory is not empty