Het grote ZFS topic

[Keiichi]

ada0p4 is trouwens maar 63G groot. Snap er niets van nu...

[Verwijderd]

Reboot gewoon eens, kijken wat er dan gebeurt.

[Compizfox]

matty___ schreef op donderdag 11 december 2014 @ 12:52:
[...]

Even los van dit probleem maar als een proces loopt en je ziet geen output kun je in FreeBSD/OSX met ctrl+t meer info krijgen over het proces en wat hij op dit moment aan het doen is.

Thanks. Die kende ik nog niet.

FireDrunk schreef op donderdag 11 december 2014 @ 13:26:
@CompizFox, is het niet zo dat omdat je de pool geimporteerd heb, het zo kan zijn dat het pool filesystem je root / overgemount heeft?

Dus als de fout daar in zit, je door het importeren van die pool, diezelfde fout in je draaiende live systeem introduceert?

Neh, het mountpoint van mijn pool is /Data. Dat kan dus niet het geval geweest zijn omdat die map /Data niet bestaat in het root FS.

CurlyMo schreef op donderdag 11 december 2014 @ 13:37:
@CompizFox, is dit wat:
http://www.mail-archive.c...solaris.org/msg40286.html

Die kwam ik ook al tegen. Toch bedankt

Ik heb uiteindelijk gewoon m'n dataset destroyed en weer opnieuw aangemaakt. Het probleem is nog niet weer teruggekomen. Wel gek, ik heb geen flauw idee waar het probleem zat. Als je zo'n error onder Linux krijgt (ext4) zou je aannemen dat het FS corrupt is en dan draai je een fsck. Onder ZFS heb je dat echter niet, en een scrub toonde geen errors...

[ Voor 8% gewijzigd door Compizfox op 12-12-2014 16:31 ]

[Gonadan]

Ok, ik ben om. Op dit moment heb ik drie schijven naast elkaar zonder trucjes, omdat RAID achterhaald was en ZFS-achtigen nog niet echt bekend. Het draait op een zelfbouw Ubuntu server met een losse OS-disk. Nu beginnen echter schijven af te haken en moeten vervangen worden, tijd om eens rond te kijken en zo kwam ZFS langs. Ik loop echter tegen twee vraagstukken aan:

offtopic:
Ter info: de server draait Ubuntu server en wordt puur gebruikt om data op te slaan, back-up te regelen en wat geautomatiseerde taken. Bediening met SSH of webinterfaces. Performance is niet erg belangrijk, zoals hij nu draait doet hij alles al lachend. Back-up wordt historisch op de machine zelf gedaan, offsite wordt nog aan gewerkt.

Op dit moment draai ik Ubuntu en ik zie het niet echt zitten om ook de hele server opnieuw te installeren, het gaan namelijk 'maar' om data opslag. Sinds het begin van het topic is er veel aan gewerkt en ik zie steeds meer mensen in het topic er gebruik van maken. Ik heb al eens zfs-dkms geinstalleerd, volgens mij gewoon uit de repo. Is er een zwaarwegende reden om hier vanaf te zien, buiten voorkeur voor OS?

Daarnaast lees ik een voorkeur voor aantallen schijven, voor RAID-Z zou dit 3, 5 of 9 moeten zijn. Echter neigt mijn voorkeur naar 4 vanwege beschikbare ruimte op het moederbord en het volgende. Drie schijven van 4TB geeft 8TB storage voor bedrag x. Vier schijven van 3TB storage geeft mij 9TB storage voor een bedrag minder dan x.

Vandaar dat ik liever voor optie twee zou gaan, maar zou ik uberhaupt iets merken van de schrijfpenalty? En uiteraard heb je een relatief lagere parity en wellicht grotere kans op falen van het gehele array?

[FireDrunk]

ZFS-dkms is maar een onderdeel, je moet ubuntu-zfs installeren vanuit de Repo, dan krijg je meer packages denk ik... (zoals mountall, welke ervoor zorgt dat je pools gemount worden tijdens boot).

4 schijven in RAIDZ kan wel, alleen is het suboptimaal, je verliest een paar procent ruimte en wat snelheid. Maar technisch gezien kan het prima. Ik draai zelf 4*4TB in RAIDZ. Als je compressie ook nog eens aanzet is het verlies van diskruimte zelfs zo goed als voorbij.

De kans van falen van 4 vs 3 schijven zou ik niet mee proberen te rekenen... Dat is koffiedik kijken... Kies liever een goede backup, en zorg voor goede monitoring, zodat je direct een mailtje krijgt als er een schijf stuk gaat ofzo.

[Verwijderd]

Als hij ashift=9 gebruikt hoeft hij niet veel ruimte te verliezen. Bij niet-optimale pools is het dus eigenlijk een keuze tussen opslagruimte (ashift=9) of performance (ashift=12).

Ik zelf zou liever 6TB schijven kiezen. Al begin je er met twee. Later schijfje bijkopen en je maakt er een RAID-Z van 3 disks van; dat kan zonder data verlies met wat instructies. Heb je 12TB ruimte en superzuinig. Nu 3TB schijven kopen kan ook; maar meh..

Bovendien zijn de 6TB versies sneller en hebben ze geen headparking tweaking meer nodig. Bij kleinere versies wel, dat kun je met WDIDLE3.EXE doen.

[Gonadan]

FireDrunk schreef op zaterdag 13 december 2014 @ 14:28:
ZFS-dkms is maar een onderdeel, je moet ubuntu-zfs installeren vanuit de Repo, dan krijg je meer packages denk ik... (zoals mountall, welke ervoor zorgt dat je pools gemount worden tijdens boot).

Dat zijn gewoon afhankelijkheden, wat mee gekomen is zijn onder andere: ubuntu-zfs, libzfs2 en zfsutils.
Daarom heb ik Ubuntu, scheelt mijzelf nadenken.

4 schijven in RAIDZ kan wel, alleen is het suboptimaal, je verliest een paar procent ruimte en wat snelheid. Maar technisch gezien kan het prima. Ik draai zelf 4*4TB in RAIDZ. Als je compressie ook nog eens aanzet is het verlies van diskruimte zelfs zo goed als voorbij.

Nu: 3x1,5 = 4,5TB
Straks:
Of: 4x2 = 6TB (340 euri)
Of: 4x3 = 9TB (436 euri)
Of: 3x4 = 8TB (435 euri)

Nog even beslissen dan.

De kans van falen van 4 vs 3 schijven zou ik niet mee proberen te rekenen... Dat is koffiedik kijken... Kies liever een goede backup, en zorg voor goede monitoring, zodat je direct een mailtje krijgt als er een schijf stuk gaat ofzo.

Mee eens. Daar moet ik toch nog eens goed naar kijken. Nu heb ik actuele kopieen op verschillende machines. Historische backup op de server, maar nog geen offsite. De server is nu een spof voor historisch backup.

Verwijderd schreef op zaterdag 13 december 2014 @ 14:39:
Ik zelf zou liever 6TB schijven kiezen. Al begin je er met twee. Later schijfje bijkopen en je maakt er een RAID-Z van 3 disks van; dat kan zonder data verlies met wat instructies. Heb je 12TB ruimte en superzuinig. Nu 3TB schijven kopen kan ook; maar meh..

Maar dan heb ik initieel niet het voordeel van RAID-Z, dat is toch ook wel weer zonde? Wat is mis met 3TB schijven? Ik ga toch niet naar enorme storagehoeveelheden.

Bovendien zijn de 6TB versies sneller en hebben ze geen headparking tweaking meer nodig. Bij kleinere versies wel, dat kun je met WDIDLE3.EXE doen.

Ik dacht dat je dat niet meer hoefde te doen? Sinds de EZRX varianten?

[ Voor 22% gewijzigd door Gonadan op 13-12-2014 15:14 ]

[Verwijderd]

Wat bedoel je met 'het voordeel van RAID-Z' ? Met een mirror heb je dezelfde bescherming. Beter nog omdat je slechts 2 disks hebt ipv 3.

Leuke van een mirror is dat je makkelijk kunt upgraden als je disks bijkoopt. Je maakt van de mirror een single disk (dat kan gewoon) en dan koop je er nog één schijf bij. Dan heb je twee lege schijven waar je een 3-disk RAID-Z van kan maken met slechts twee disks en één nep-disk (memory disk). Na het rebooten is die pool degraded omdat de memory disk weg is. Dan kun je data overkopiëren van de voormalige mirror die nu dan een single disk pool is, naar de degraded RAID-Z. Zodra dit voltooid is, kun je de oude pool destroyen en de vrijgekomen disk aan de RAID-Z schenken zodat deze niet meer degraded is. Et voila: een upgrade van 2-disk mirror naar 3-disk RAID-Z zonder dataverlies.

[Hakker]

Op elke WD Green schijf zal je WDIDLE3 moeten draaien maakt niet uit of het 1TB of 6TB is. Ik heb geen idee hoe je erbij komt dat dit bij de 6TB versies het ineens niet meer op de Green svhrijven zou zitten want intellipark zoals WD het noemt is juist 1 van de reden dat het een Green schijf is.

[Verwijderd]

Ik heb zelf de WD60EZRX en deze heeft zonder tweaking geen last van snel stijgende LCC. Mijn WD40EZRX daarentegen wel. Zeer waarschijnlijk is dat WD de headparking timer verder heeft getuned. Het is wel mogelijk dat andere Greens ook dergelijke firmware tweaks krijgen; maar dit kun je niet afleiden aan het typenummer.

Bovendien, de WD60EZRX ondersteunt niet meer de tweak om headparking uit te schakelen via APM setting 254, zoals mijn WD40EZRX wel ondersteunen. WDIDLE3.EXE heb ik niet uitgeprobeerd op deze disks.

@FireDrunk: ik heb de schijf en tijd 24/7 aan gehad bij een exported pool; dus dat lijkt me een vrij goede test. Ik heb hem momenteel uit staan, dus kan geen SMART queryen. Maar zal binnenkort kijken of ik het kan bevestigen.

[ Voor 41% gewijzigd door Verwijderd op 13-12-2014 15:34 ]

[FireDrunk]

Dat ligt natuurlijk ook aan het gebruik, als jij een continue stream aan data van die schijf vraagt zal hij niet parken...

[funnyname]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:21:
Wat bedoel je met 'het voordeel van RAID-Z' ? Met een mirror heb je dezelfde bescherming. Beter nog omdat je slechts 2 disks hebt ipv 3.

Leuke van een mirror is dat je makkelijk kunt upgraden als je disks bijkoopt. Je maakt van de mirror een single disk (dat kan gewoon) en dan koop je er nog één schijf bij. Dan heb je twee lege schijven waar je een 3-disk RAID-Z van kan maken met slechts twee disks en één nep-disk (memory disk). Na het rebooten is die pool degraded omdat de memory disk weg is. Dan kun je data overkopiëren van de voormalige mirror die nu dan een single disk pool is, naar de degraded RAID-Z. Zodra dit voltooid is, kun je de oude pool destroyen en de vrijgekomen disk aan de RAID-Z schenken zodat deze niet meer degraded is. Et voila: een upgrade van 2-disk mirror naar 3-disk RAID-Z zonder dataverlies.

Maar dan kan je toch beter 2 mirrors van 2 * 3 TB kiezen, dit is goedkoper en waarschijnlijk sneller dan 2 * 6TB mirror?

(die upgrade methode had ik nog niet aan gedacht, slim om het zo op te lossen)

[Gonadan]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:21:
Wat bedoel je met 'het voordeel van RAID-Z' ? Met een mirror heb je dezelfde bescherming. Beter nog omdat je slechts 2 disks hebt ipv 3.

Ah, ik dacht niet aan mirror maar gewoon twee losse schijven.

Die optie is in verhouding echter nogal duur, de reden om naar RAID-Z te kijken is mede vanwege prijs per TB. Daarnaast ben ik niet van plan te upgraden. Ik ga nu een systeem neerzetten en als er ooit wat bij komt is dat een geheel los array vermoed ik.

Wat is jouw aversie tegen de 3TB optie? De beperkte opslag en dus relatief weinig ruimte per 'slot in je server'?

Leuke van een mirror is dat je makkelijk kunt upgraden als je disks bijkoopt. Je maakt van de mirror een single disk (dat kan gewoon) en dan koop je er nog één schijf bij. Dan heb je twee lege schijven waar je een 3-disk RAID-Z van kan maken met slechts twee disks en één nep-disk (memory disk). Na het rebooten is die pool degraded omdat de memory disk weg is. Dan kun je data overkopiëren van de voormalige mirror die nu dan een single disk pool is, naar de degraded RAID-Z. Zodra dit voltooid is, kun je de oude pool destroyen en de vrijgekomen disk aan de RAID-Z schenken zodat deze niet meer degraded is. Et voila: een upgrade van 2-disk mirror naar 3-disk RAID-Z zonder dataverlies.

Leuke truc.

[FireDrunk]

funnyname schreef op zaterdag 13 december 2014 @ 15:34:
[...]


Maar dan kan je toch beter 2 mirrors van 2 * 3 TB kiezen, dit is goedkoper en waarschijnlijk sneller dan 2 * 6TB mirror?

(die upgrade methode had ik nog niet aan gedacht, slim om het zo op te lossen)

Sneller vast, maar is dat nuttig? 2 schijven van 6TB lezen samen 300MB/s en schrijven dik 150MB/s.
Heb jij een use-case waar dat niet genoeg is?

[Gonadan]

Hoe moet ik deze post dan zien? (uit ander topic)

Verwijderd schreef op zaterdag 08 februari 2014 @ 16:22:
De oudere WD Greens (EARS) hadden erg agressieve headparking, maar bij de nieuwe EZRX greens hoef je niets te veranderen; dat staat standaard al prima afgesteld. WD Red heeft Headparking helemaal uitgeschakeld en dat vind ik een nadeel ten opzichte van Green, geen voordeel.

Bij de oudere WD Green dien je bij elke boot APM 254 in te stellen om de headparking uit te schakelen; bij de nieuwe Greens is dat dus niet meer nodig.

Niet meer geldig?

[Verwijderd]

Het klopt dat je met meer schijven efficientere pools met RAID-Z kunt bouwen; minder overhead.

Echter, ik zelf koop liever spul wat toekomstbestendig is. Dat betekent dus zo groot mogelijke disks tenzij dit de prijs-per-gigabyte flink aantast. De 6TB Greens doen het op dat gebied nog vrij redelijk; je betaalt niet zoveel extra - maar in verhouding nog wel ietsje duurder dan de 4TB of 3TB versies. Maar dat scheelt niet veel last time i checked.

Zou je later meer opslag willen, kun je met de dan gangbare schijven makkelijker upgraden en een grotere pool maken. In de toekomst ga je geen 2TB of 3TB schijven meer kopen; die zijn dan juist verhoudingsgewijs duur.

Verder speelt zuinigheid een rol. Minder schijven betekent lagere idle power. De 6TB versies verbruiken grofweg hetzelfde als de 2TB greens; de idle-watt-per-terabyte verhouding is dus veel beter. Verder kun je met weinig schijven ook af zonder ATX-voeding, wat nog de meeste verschil gaat geven qua idle power. PicoPSU of een DC-DC voeding is gewoon zuiniger. Bovendien weer een ventilator minder en iets wat mechanisch stuk kan gaan. En een lomp grote ATX voeding heb je dan ook niet meer nodig.

Als laatste zijn de nieuwe 6TB Greens sneller omdat ze 1200GB platters hebben, terwijl de 5TB en lagere versies gebruik maken van 1000GB platters. Dit betekent dat de 6TB Green tot 175MB/s doet wat voor 5400rpm-class een goede prestatie is. 4TB doet 150MB/s uit mijn hoofd.

Besef ook dat je wat ruimte op je pool vrij wilt houden; dus wat marge nemen is denk ik best goed. Zou je beginnen met een mirror van 6TB schijven en later uitbreiden met een disk zodat je 3-disk RAID-Z hebt, heb je een zuinig en toekomstbestendig systeem. Later zou je drie diskjes bij kunnen halen voor een 6-disk RAID-Z2 of een 10-disk RAID-Z2 wat je wilt.

Het is maar een idee hoor; je kunt ook prima gaan voor de 3TB of 4TB versies. Bovenstaande is meer mijn persoonlijke voorkeur en kijk op de zaak. Kun je meewegen in je beslissing.

[funnyname]

Ik heb niet echt een use-case, maar een duurdere oplossing die ook nog minder performance geeft klinkt niet als de beste oplossing

[FireDrunk]

6TB zou ik persoonlijk ook (nog) niet zomaar doen... Tenzij je er geen probleem mee hebt om met vrij dure schijven te upgraden... 4TB is net iets betaalbaarder, en als je moet uitbreiden zijn dat nog behapbare bedragen...

Maar dat is meer gevoel/mening dan feit.

[Verwijderd]

Gonadan schreef op zaterdag 13 december 2014 @ 15:40:
Hoe moet ik deze post dan zien? (uit ander topic)

Niet meer geldig?

Ik zou die quote van mij inderdaad wel willen herzien. Het klopt wel dat EARS vroeger extreem agressieve headparking had en de EZRX van nu al veel rustiger staat afgesteld. Maar nog steeds niet voldoende om bij 24/7 NAS gebruik de LCC binnen de perken te houden. Mijn EZRX heb ik een tijdje zonder APM-tweak gebruikt zonder dat ik het door had en dat vond ik toch enigszins zonde. Geen idee wat de LCC nu is.

Dus mijn huidig advies zou zijn om voor alle <6TB Greens de WDIDLE3.EXE utility te gebruiken en de headparking timer op 300 seconden in te stellen. Dan heb je wel de voordelen van headparking, maar niet het nadeel van overmatige slijtage omdat de LCC ver oploopt.

[funnyname]

Wat betreft verbruik en snelheid per schijf ben ik het helemaal met je eens. Als je daar nu een kleine voeding op afstemt heb je een energie zuinige server. Maar dan in de toekomst wil je inderdaad upgraden met extra schijven, gaat die voeding het dan nog steeds aan kunnen, of moet je dan ook je voeding upgraden?

Ik zie dat jullie het hebben over WD Geen, is de RED serie niet beter geschikt om 24/7 aan te staan en gaan deze daarom niet langer mee in een NAS?

[Verwijderd]

@funnyname: besef wel dat een ZFS mirror als een RAID0 kan lezen terwijl dat bij RAID-Z niet kan. Besef ook dat de 6TB versies van nature iets sneller zijn. Dus dat nullificeert deels het performance voordeel dat een 3-disk RAID-Z zou hebben boven 2-disk mirror.

WD Red is fysiek ook gelijk aan WD Green afgezien van garantie, TLER firmware, permanent uitgeschakelde headparking (=nadeel) en een vibratiesensor. Dat laatste ben ik nog niet uit hoe belangrijk dat is voor een kleine NAS. Ik denk dat het pas relevant wordt als je veel schijven in een rack hebt waar resonanties kunnen voorkomen. Ik heb mijn schijven in een stevig metalen rack die goed weerstand krijgt, dus vibraties en resonanties zijn in mijn situatie nihil.


@FireDrunk: net even uitgerekend wat het prijsverschil verhoudingsgewijs is:
140 euro voor 4TB = 35 euro per TB
232 euro voor 6TB = 38,66 euro per TB

Dus wel iets duurder, maar valt nog best mee vind ik. De 6TB schijf wil ik gaan gebruiken om mijn 24/7 online NAS mee te voeden; mijn grote RAID-Z2 NASsen staan doorgaans uit. Ik ben idle power freak dat weet je.

De always on NAS heeft geen data die niet op de overige disks staan, dus single disk pool is geen risico. Maar dat zorgt wel voor heel lage idle power.

[Hakker]

trouwens CiPHER is kan al 1,5 maand niet inloggen op het forum omdat Firefox hier borked is gegaan Jason reageert dus ook voor geen ene meter op pw reset requests. Ik begin dat uitstel gebeuren behoorlijk zat te worden.

Daarnaast EARS en EZRX staan beide op 8 seconden ik heb van beide schijven dus ze staan net zo aggressief afgesteld, en bij Red's staan ze niet uit maar op 300.

Dus als je WDIDLE3.EXE /S300 doet op je Greens maak je eigenlijk gewoon RED's want de andere voordelen van RED's gebruik je in ZFS niet.

[Gonadan]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:41:
Het klopt dat je met meer schijven efficientere pools met RAID-Z kunt bouwen; minder overhead.

Echter, ik zelf koop liever spul wat toekomstbestendig is. Dat betekent dus zo groot mogelijke disks tenzij dit de prijs-per-gigabyte flink aantast. De 6TB Greens doen het op dat gebied nog vrij redelijk; je betaalt niet zoveel extra - maar in verhouding nog wel ietsje duurder dan de 4TB of 3TB versies. Maar dat scheelt niet veel last time i checked.

Ok, mijn ervaring is juist dat kopen op de toekomst met computerapparatuur vaak alleen maar duur is en weinig voordeel biedt.

Even inhoudelijk, de combinaties van 3 of 4TB schijven geeft 8 of 9 TB storage voor 430 dus 48 euro per TB. De 6TB optie geeft 6TB voor 500 euro. Dus 83 euro per TB. Wellicht maakt winkel nog uit maar ik vergelijk het nu even bij dezelfde.

Zou je later meer opslag willen, kun je met de dan gangbare schijven makkelijker upgraden en een grotere pool maken. In de toekomst ga je geen 2TB of 3TB schijven meer kopen; die zijn dan juist verhoudingsgewijs duur.

Verder speelt zuinigheid een rol. Minder schijven betekent lagere idle power. De 6TB versies verbruiken grofweg hetzelfde als de 2TB greens; de idle-watt-per-terabyte verhouding is dus veel beter. Verder kun je met weinig schijven ook af zonder ATX-voeding, wat nog de meeste verschil gaat geven qua idle power. PicoPSU of een DC-DC voeding is gewoon zuiniger. Bovendien weer een ventilator minder en iets wat mechanisch stuk kan gaan. En een lomp grote ATX voeding heb je dan ook niet meer nodig.

Als laatste zijn de nieuwe 6TB Greens sneller omdat ze 1200GB platters hebben, terwijl de 5TB en lagere versies gebruik maken van 1000GB platters. Dit betekent dat de 6TB Green tot 175MB/s doet wat voor 5400rpm-class een goede prestatie is. 4TB doet 150MB/s uit mijn hoofd.

Besef ook dat je wat ruimte op je pool vrij wilt houden; dus wat marge nemen is denk ik best goed. Zou je beginnen met een mirror van 6TB schijven en later uitbreiden met een disk zodat je 3-disk RAID-Z hebt, heb je een zuinig en toekomstbestendig systeem. Later zou je drie diskjes bij kunnen halen voor een 6-disk RAID-Z2 of een 10-disk RAID-Z2 wat je wilt.

Prestaties zijn nu al ruim voldoende en de rest staat er al dus extra zuinigheid zou niet veel opleveren. ATX zit er al in. Voor de toekomst ben ik het met je overwegingen eens, maar het gaat nu zuiver om het vervangen van defecte schijven, niet het bouwen van een nieuwe NAS.

De extra ruimte ben ik wel met je eens, ik heb ook 4 keer 2TB overwogen, maar daarmee ga ik van 4,5 naar 6. Dat is niet heel optimaal aangezien ik nu vaak al krap zit.

Het is maar een idee hoor; je kunt ook prima gaan voor de 3TB of 4TB versies. Bovenstaande is meer mijn persoonlijke voorkeur en kijk op de zaak. Kun je meewegen in je beslissing.

Ik neem je uitleg ook zeker mee hoor, vind het juist altijd goed om andere visies te horen. Als ik dan kies weet ik zeker dat het weloverwogen is.

Verwijderd schreef op zaterdag 13 december 2014 @ 15:45:
Ik zou die quote van mij inderdaad wel willen herzien. Het klopt wel dat EARS vroeger extreem agressieve headparking had en de EZRX van nu al veel rustiger staat afgesteld. Maar nog steeds niet voldoende om bij 24/7 NAS gebruik de LCC binnen de perken te houden. Mijn EZRX heb ik een tijdje zonder APM-tweak gebruikt zonder dat ik het door had en dat vond ik toch enigszins zonde. Geen idee wat de LCC nu is.

Dus mijn huidig advies zou zijn om voor alle <6TB Greens de WDIDLE3.EXE utility te gebruiken en de headparking timer op 300 seconden in te stellen. Dan heb je wel de voordelen van headparking, maar niet het nadeel van overmatige slijtage omdat de LCC ver oploopt.

Duidelijk, dan doe ik dat toch gewoon? Al las ik dat het bij elke boot moest, is dat niet iets wat je vast kunt zetten?

[Verwijderd]

Voor zowel Jason als mijzelf is het enorm doorwerken om alles deze maand af te krijgen, dus probeer ajb een nieuwe registratie te doen? Nieuwe website betekent binnenkort toch dat je opnieuw moet reggen, dus veel maakt het niet uit dat je een andere naam hebt.

Maar als je wilt, kun je me DMen; het kost mij alleen veel moeite om het password te resetten van het huidige systeem. Opnieuw reggen is wellicht makkelijker.

Wat je zegt over WD Red is voor mij nieuw; ik dacht deze juist headparking helemaal had uitgeschakeld. Als deze standaard op 300 seconden staan, is dat juist perfect wat mij betreft. Maar om daarvoor de Reds te overwegen zou ik zonde vinden; een beetje moeite met WDIDLE3.EXE kun je dat geld uitsparen. Bovendien zou het BackBlaze-onderzoek uitwijzen dat de Greens niet substantieel veel uitvallen tussen het 2e en 3e jaar, al dien je dat met korrel zout te nemen natuurlijk.

[funnyname]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:54:
@funnyname: besef wel dat een ZFS mirror als een RAID0 kan lezen terwijl dat bij RAID-Z niet kan. Besef ook dat de 6TB versies van nature iets sneller zijn. Dus dat nullificeert deels het performance voordeel dat een 3-disk RAID-Z zou hebben boven 2-disk mirror.

Ik ging uit van 2 x 3TB mirror (4 schijven) t.o.v. 1 x 6 TB mirror (2 schijven) RAIDZ is altijd langzamer lijkt me, het schrijven van de extra parity kost toch tijd..

Dat is trouwens wellicht aan nadeel van de upgrade truc van mirror naar RAIDZ, je performance zal wel minder worden, ook al heb je meer schijven?

[Verwijderd]

Dual mirror is natuurlijk onzin; dan neem je een 4-disk RAID-Z2 als je hoge bescherming wilt, dat is superieur aan een dual mirror.

Hoezo zou de performance minder worden? Aangezien je data opnieuw schrijft naar een lege verse RAID-Z pool - zij het degraded - is er geen enkele reden om dat te veronderstellen. Toch?

[Compizfox]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:21:
Wat bedoel je met 'het voordeel van RAID-Z' ? Met een mirror heb je dezelfde bescherming. Beter nog omdat je slechts 2 disks hebt ipv 3.

Voordelen met RAID-Z boven mirroring:

- Minder ruimte kwijt aan parity. Met mirroring ben je de helft kwijt, bij RAID-Z1 maar een derde. Dit kan natuurlijk ook een nadeel zijn, maar persoonlijk vind ik RAID-Z1 een mooi compromis.

- RAID-Z is sneller met schrijven dan mirroring.

[Gonadan]

Verwijderd schreef op zaterdag 13 december 2014 @ 15:54:
@FireDrunk: net even uitgerekend wat het prijsverschil verhoudingsgewijs is:
140 euro voor 4TB = 35 euro per TB
232 euro voor 6TB = 38,66 euro per TB

Die rekenmethode vind ik niet geheel eerlijk, ik reken graag met de ruimte die ik kan gebruiken.
Dus:
430 euro voor 4 3TB schijven, 9TB bruikbaar = 48 euro per TB
500 euro voor 2 6TB schijven, 6TB bruikbaar = 83 euro per TB

Natuurlijk wordt de rekensom anders als je de schijven later anders gaan inzetten, maar dat zal bij mij voor 99% zeker niet het geval zijn. Dan reken ik liever met de praktijk.

[funnyname]

In verband met performance vroeg ik me nog af, heeft iemand ervaring met NIC teaming? Want het lijkt me dat de netwerk snelheid de grootste bottleneck is. Ik overweeg dit te gaan toepassen..

[Verwijderd]

@Compizfox: Klopt, maar ik stelde het enkel voor zodat bij 6TB schijven hij met een mirror van 2 disks kan beginnen, en later kan uitbreiden naar 3 disks in RAID-Z. Dus de mirror is tijdelijk.

@Gonandan: als je de mirror niet meerekent in je beslissing, omdat die toch een RAID-Z gaat worden, maakt dat verder niet uit. Dus dan vergelijk je 3-disk RAID-Z met 6TB disks (=12TB effectief) met 3-disk RAID-Z met 4TB disks (=8TB effectief).

Als jij zeker weet dat je niet zoveel ruimte nodig hebt, zou ik je gewoon een 3-disk RAID-Z van 4TB Greens aanbevelen. Wel even de WDIDLE3.EXE utility gebruiken dus.

@funnyname: ja iedereen hier wilt wel sneller dan gigabit. Maar het is tricky, kort gezegd. Beste is de nieuwste Thunderbolt spec (3.0 uit mijn hoofd) die een 20Gbps ethernet bridge mogelijk zou maken tussen twee computers en nog redelijk betaalbaar. Dat zou ik op termijn graag willen voor mijzelf. 10GBaseT heb ik opgegeven; veels te duur.

[ Voor 38% gewijzigd door Verwijderd op 13-12-2014 16:17 ]

[Compizfox]

funnyname schreef op zaterdag 13 december 2014 @ 16:12:
In verband met performance vroeg ik me nog af, heeft iemand ervaring met NIC teaming? Want het lijkt me dat de netwerk snelheid de grootste bottleneck is. Ik overweeg dit te gaan toepassen..

Dat hangt er vanaf welk protocol je gebruikt. Mijn ervaring is dat je met Samba of NFS je gigabit-lijntje niet eens voltrekt.

Kan natuurlijk ook komen door overhead van Samba op de netwerkverbinding zelf, dat weet ik niet. In dat geval zou het wel helpen om een snellere netwerkverbinding te hebben.

[funnyname]

Ik zou ook nog iSCSI kunnen overwegen, maar das toch minder flexibel

[funnyname]

Verwijderd schreef op zaterdag 13 december 2014 @ 16:13:
@funnyname: ja iedereen hier wilt wel sneller dan gigabit. Maar het is tricky, kort gezegd. Beste is de nieuwste Thunderbolt spec (3.0 uit mijn hoofd) die een 20Gbps ethernet bridge mogelijk zou maken tussen twee computers en nog redelijk betaalbaar. Dat zou ik op termijn graag willen voor mijzelf. 10GBaseT heb ik opgegeven; veels te duur.

Juist omdat 10GB zo duur is (en eigenlijk ook weer overkill), leek me NIC teaming een betaalbare middenweg. Je hebt een switch nodig die het ondersteund, die kost ongeveer €60 en in ieder systeem twee netwerk kaarten per systeem, thats it.
Wordt Thunderbolt al goed ondersteund op de UX-achtige OS-en die ZFS draaien?

[Gonadan]

Verwijderd schreef op zaterdag 13 december 2014 @ 16:13:
@Gonadan: als je de mirror niet meerekent in je beslissing, omdat die toch een RAID-Z gaat worden, maakt dat verder niet uit. Dus dan vergelijk je 3-disk RAID-Z met 6TB disks (=12TB effectief) met 3-disk RAID-Z met 4TB disks (=8TB effectief).

Als jij zeker weet dat je niet zoveel ruimte nodig hebt, zou ik je gewoon een 3-disk RAID-Z van 4TB Greens aanbevelen. Wel even de WDIDLE3.EXE utility gebruiken dus.

Dan wordt het:
430 euro voor 4 3TB schijven, 9TB bruikbaar = 48 euro per TB
750 euro voor 3 6TB schijven, 12TB bruikbaar = 63 euro per TB

Nog steeds significant duurder, maar dat komt simpelweg door de 4 schijven in de 3TB opstelling. 25% pariteit is natuurlijk gewoon goedkoper dan 33% of 50%
Vanwaar dan de voorkeur voor 3x4 ipv 4x3? Die 1TB storage die je verliest is acceptabel ten opzichte van het performance en storage verlies van een verkeerd aantal schijven in ZFS?

Qua zeker weten van hoeveelheid, dat weet je nooit. Maar ik doe nu vijf jaar met 4,5TB () en heb het eigenlijk altijd wel gered, hooguit soms wat series weg moeten gooien die ik eigenlijk al gezien had.
Ik vermoed ook dat tegen de tijd dat ik weer wil upgraden mijn hele server wel aan vervanging toe is. 24/7 aan zal ook de andere hardware doen slijten.

[FireDrunk]

_{Als je al 5 jaar met 4.5GB toe kan, waarom dan uberhaupt > 1TB schijven}

Als je alle sata poorten dicht propt, kan je niet eens met 1 schijf uitbreiden, dat is dan wel weer zonde...

[Verwijderd]

Volgens mijn berekening:

420 euro voor 3x 4TB schijven, 8TB bruikbaar = 52,50 euro per TB
696 euro voor 3x 6TB schijven, 12TB bruikbaar = 58,00 euro per TB

Bedenk ook dat als je 3TB schijven neemt en dus een extra schijf, je ook 8 euro per jaar moet meerekenen als extra energiekosten. Bovendien heb je dan een niet-optimale 4-disk pool ipv een optimale 3-disk RAID-Z pool.

[Gonadan]

Op dit moment heb ik zes poorten, 1 voor OS, 3 voor storage, 2 vrij.
Welke keuze het ook wordt, ik wil er minimaal 1 vrij houden om de huidige schijven te kunnen leeg trekken. Dus kan het prima 4 zijn.

Aan de andere kant is 3 weer interessant omdat je dan twee slots over houdt, eventueel in de toekomst is een mirror dus mogelijk.

De suboptimale set kost ruimte en performance, maar over hoeveel spreken we dan? Enkele procenten of een halve TB storage kwijt?

[Verwijderd]

Zie:



Bedenk wel dat Data disks betekent dat je de parity schijven moet weglaten. Dus een 3-disk RAID-Z heeft 2 data disks. Een 10-disk RAID-Z2 heeft 8 data disks.

Gerelateerd hieraan:

FireDrunk schreef op zaterdag 13 december 2014 @ 14:28:
Als je compressie ook nog eens aanzet is het verlies van diskruimte zelfs zo goed als voorbij.

Dan moet je volgens mij wel LZJB of GZIP compressie gebruiken. Want bij LZ4-compressie betekent dit dat bij binaire data (wat bij onze NAS systemen 95%+ van de data is) dat de data effectief niet is gecomprimeerd. Dan zou ook het space-efficiency voordeel van compressie niet opgaan, volgens mij. Maar dat weet ik niet 100% zeker.

[ Voor 43% gewijzigd door Verwijderd op 13-12-2014 16:44 ]

[Gonadan]

Dus bij een array van 4 (3 data dus) doet de 4K variant het nog slechter? Maar beiden zijn suboptimaal zie ik, dat zal die performance/ruimte afweging zijn waar je het eerder over had. Maar als ik zo moet schatten praat je dus maximaal over 3%?

Weet je wat nu zo 'vervelend' is? Je triggert wel de perfectionist in mij.

Compressie zal weer ten koste gaan van de performance mag ik aannemen?

[ Voor 10% gewijzigd door Gonadan op 13-12-2014 16:47 ]

[FireDrunk]

Volgens mij is de interne structuur van Compressie stripes dusdanig anders dat je niet meer tegen die 128k stripe write barrier aan loopt, maar waarom weet ik ook niet meer...

Nee hoor, Compressie zal op een moderne CPU alleen maar snelheidswinst geven... je kan namelijk sneller lezen dan je disks kunnen lezen... Die lezen namelijk de gecomprimeerde data in, en je CPU pakt het sneller uit dan zij het lezen, dus haal je soms effectief meer dan je disks aan kunnen.

[ Voor 45% gewijzigd door FireDrunk op 13-12-2014 16:53 ]

[Verwijderd]

Ha ha, nou ik ben ook perfectionistisch, dus daarom ben ik ook op zoek naar sweet spots en hoogste efficiency. Maar het zijn veel factoren die je tezamen moet overwegen en elke situatie is anders.

In jouw geval denk ik dat je prima 3 keer 4TB disks in RAID-Z kunt overwegen. 4 schijven zou ik zelf niet doen, zeker niet als je de ruimte niet nodig hebt zoals je zelf zegt. Dan zou ik eerder 3 disks van 6TB overwegen en wellicht tot die tijd met 2x 6TB in mirror doen totdat je de extra ruimte nodig hebt, zoals ik eerder voorstelde. Heb je die ruimte niet nodig; dan is 3x 4TB voor jou toch de beste keus?

In het plaatje is 'ideal' bij een sector size van 1 byte; dergelijke disks bestaan niet dus 512B is het kleinste. Dan heb je een kleine overhead. Bij 4K wordt de overhead veel groter. Maar bij 3 data disks (dus 4-disk RAID-Z) is dat nog relatief beperkt. Bedenk wel dat 4K betekent dat je pool ashift=12 is. Als je wel moderne disks koopt met 4K fysieke sectors, dan hebben die 512B logische sectors via emulatie. Dat betekent dat je ook gewoon een ashift=9 pool kunt maken wat dus inhoudt dat ZFS 512-byte sectors gebruikt. Ashift=12 betekent dat ZFS de disks als 4K sector disks beschouwt. Bij niet-optimale configuraties betekent dat verlies van bruikbare opslagruimte.

Voor niet-optimale RAID-Z configuraties is er dus een keuze tussen meer opslagruimte (ashift=9) en hogere performance (ashift=12). Bij optimale RAID-Z configuraties heb je beide voordelen.

[Gonadan]

Los van de exacte grootte komt het neer op:

Pool van 3 ten opzichte van 4
+ meetbaar minder storageverlies vanwege optimale pool
+ meetbaar betere prestaties vanwege optimale pool
+ meer ruimte over op moederbord
+ minder stroomverbruik
- merkbaar minder storage vanwege hoger pariteitspercentage

Feitelijk komt het er dan op neer of ik die ene TB meer waard vind dan het stroomverbruik en wat theoretische betere prestaties. Of zie ik wat over het hoofd? (behalve wellicht een voorraad s-atakabels )

[FireDrunk]

Betere prestaties gaat alleen om Random IO, sequentieel zal je er niets van merken volgens mij...
Stroomverbruik is ook verwaarloosbaar, want je krijgt er meer TB voor terug?

[Gonadan]

Even verder gezocht op implementatie (houdt het ook meer on topic )

Zodra ik de schijven heb is het dan slim om eerst die WDIDLE te doen? Ik zag vaak genoeg mensen die ze een voor een op het eerste slot moeten doen ofzo?

Als ze er knap in hangen is het zo simpel als:

code:

zpool create -o ashift=9 -f onwijzezfsopslagbak raidz /dev/sdb /dev/sdc /dev/sdd

Uiteraard afhankelijk van het gekozen aantal schijven en de locaties.

Daarna is alles klaar en kan je gewoon los?

@FireDrunk: haha, jullie twee TS'en zijn het niet overal over eens he?

[funnyname]

zpool create -o ashift=9 -f minderefficienteonwijzezfsopslagbak raidz /dev/sdb /dev/sdc /dev/sdd /dev/sde

zpool create -o ashift=12 -f onwijzezfsopslagbak raidz /dev/sdb /dev/sdc /dev/sdd

:-)

[FireDrunk]

@Gonodan, tuurlijk niet, zou gek zijn

[Gonadan]

Nou, als het goed is komt straks de postbode met mijn spullen. Ook maar meteen een router besteld want de tien jaar oude Linksys begint toch wat beperkt te worden.

Nu eerst een dist-upgrade aan het doen, liever dat alles knap draait voordat ik begin met een nieuwe pool dan dat ik het achteraf weer ga slopen.

Ben wel benieuwd, de hoeveelheid RAM kan wel eens uitgebreid moeten gaan worden, die is nu wat mager.

[Tadream]

Verwijderd schreef op vrijdag 29 november 2013 @ 08:34:

Tot slot: compressie, copies=2, dedupe en andere attributen worden pas actief voor nieuw geschreven data. Bestaande data wordt niet aangepast. Wil je bestaande data comprimmeren, dan zul je het mapje moeten kopiëren en dan de oude locatie verwijderen. Zoals:
zfs create tank/newshare
zfs set compression=lz4 tank/newshare
cp -Rp /tank/share/* /tank/newshare/
zfs destroy tank/share
zfs rename tank/newshare tank/share

Ik weet het, een oude quote. Maar sinds vandaag heb ik ook LZ4 aan staan.
Heb een bestaande tank/home share met diverse subfolders/bestanden.
De LZ4 compressie heb ik aangezet op tank/home.
Mijn vraag is: als ik nu een nieuwe subfolder maak op die tank/home en kopieer van een
bestaande subfolder naar een nieuwe subfolder is die dan ook gecomprimeerd?
Of moet ik echt een zfs create doen?
De oude/bestaande subfolder verwijder ik daarna uiteraard.

[CurlyMo]

@Tadream, doe jezelf een lol en doe dat met ZFS send/receive en niet op de standaard cp manier. Linkjes naar mijn forum posts staan in de TS.

[Gonadan]

Die term 'tank' ben ik wel vaker tegen gekomen. Is dat iets speciaals of gewoon een standaardnaam voor een ZFS pool in bepaalde tutorials?

[Verwijderd]

Komt denk ik van storage tank. Het is gewoon een soort van conventie, net als 'foo bar' wordt gebruikt in veel voorbeelden.

[Gonadan]

Noem jij hem op je eigen systemen ook zo dan?

[Verwijderd]

Nee, maar ik gebruik wel altijd lower-case pool namen, terwijl ik merk dat ZFS newbies altijd beginnen met een hoofdletter. Dat is tegen de algemene unix-conventie die user names en directorynamen altijd lower-case houden.

Mijn pools heten b.v.: green, guru, samsung, seagate. Mijn disks noem ik b.v. 'ezrx4a' wat wil zeggen ezrx is de schijf type, 4 is disk 4 en a wil zeggen de eerste bruikbare partitie (na de boot partitie). In sommige gevallen heb ik ook b en c vooral als het een SSD betreft.

[Gonadan]

Je bedoelt Windowsgebruikers die een ZFS-NAS willen.

Ok, dus geen sda/sdb voor jou? Werk je met UUID?

[Tadream]

CurlyMo schreef op zondag 14 december 2014 @ 12:39:
@Tadream, doe jezelf een lol en doe dat met ZFS send/receive en niet op de standaard cp manier. Linkjes naar mijn forum posts staan in de TS.

Thanks.
Ben nog vrij nieuw in de ZFS wereld en had me nog niet verdiept in
de snapshot en send/receive opties.
Oftewel heb net een snapshot gemaakt van m'n dataset en hem met gzip naar m'n homefolder aan het zetten (de ruimte is er gelukkig).
Dan de dataset leegmaken en de gz receiven op de lege dataset.
Eigenlijk heel simpel en tegelijkertijd ook vrij krachtig.

Zo kan je zeker ook als je een nieuwe grotere pool zou aanmaken met meerdere disken, al je bestanden uit die gz weer kunnen importeren/receiven in die nieuwe pool? Omdat ik lees dat je geen schijven erbij kan plaatsen.
Of is daar een deftigere oplossing voor? (wat die send/receive eigenlijk al is).

[CurlyMo]

Jammer dat je nu net het voorbeeld voor het verkeerde doel gebruikt. ZFS send naar een bestand is natuurlijk voor langdurige opslag doeleinden. Probeer anders eerst dit eens:
CurlyMo in "Het grote ZFS topic"

[Verwijderd]

CurlyMo: is het niet zo dat als hij send/receive gebruikt dat ook de attributen als compressie behouden blijven? Of wordt daadwerkelijk de bestaande data opnieuw gecomprimeerd?

[CurlyMo]

code:

# zfs create data/test
# zfs create data/test1
# zfs set compression=off data/test
# zfs get compression data/test
NAME       PROPERTY     VALUE     SOURCE
data/test  compression  off       local
# zfs set compression=lz4 data/test1
# zfs get compression data/test1
NAME        PROPERTY     VALUE     SOURCE
data/test1  compression  lz4       local
# (cd /data/test/; /root/zfs_test)
# md5 /data/test/test.bin
MD5 (/data/test/test.bin) = 430a783236c1ffa971dd606b436f7279
# zfs get compressratio data/test
NAME       PROPERTY       VALUE  SOURCE
data/test  compressratio  1.00x  -
# zfs snapshot data/test@test
# zfs list -t snapshot -r data/test
NAME             USED  AVAIL  REFER  MOUNTPOINT
data/test@test      0      -   100M  -
# zfs send -R data/test@test | zfs receive -Fvu data/test1
receiving full stream of data/test@test into data/test1@test
received 100MB stream in 2 seconds (50.1MB/sec)
# zfs list -t snapshot -r data/test1
NAME              USED  AVAIL  REFER  MOUNTPOINT
data/test1@test      0      -   100M  -
# zfs get compression data/test1
NAME        PROPERTY     VALUE     SOURCE
data/test1  compression  lz4       local
# md5 /data/test1/test.bin
MD5 (/data/test1/test.bin) = 430a783236c1ffa971dd606b436f7279
# zfs get compressratio data/test1
NAME        PROPERTY       VALUE  SOURCE
data/test1  compressratio  31.40x  -

Het zfs_test programma kan je hier vinden:
https://github.com/xudonax/zfs_test

Conclusie, niet als je zfs receive niet ook je filesystem laat maken

Zou ook een mooie boel wezen als dat niet kon. Dan kon je namelijk nooit een ZFS send/receive doen tussen bijv. een pool v28 en v5000. Dat kan dus wel . Hij dropt dan alleen alle niet ondersteunde attributen.

[ Voor 17% gewijzigd door CurlyMo op 14-12-2014 14:48 ]

[Verwijderd]

Je test is niet helemaal goed. Je zou eerst een zerofile moeten schrijven, daarna compressie enablen, daarna de zfs/send receive moeten doen. Het is pas succesvol als het resultaat is dat de target fs (zfs receive) compressed is, en de bron fs (zfs send) niet compressed.

[CurlyMo]

Ow, dat was wat je bedoelde. Ik dacht dat je vraag was of een ZFS send altijd alle attributen meeneemt naar zijn target. Dat is dus niet zo. Ik zou zeggen probeer het eens

[Verwijderd]

Weinig tijd; zit te stressen om ZFSguru release voordat ik op vakantie ga.

[CurlyMo]

Ik heb het voorbeeld aangepast om ook die vraag te beantwoorden.

[Verwijderd]

Helemaal toppie

[Gonadan]

code:

  pool: data1
 state: ONLINE
  scan: none requested
config:

        NAME        STATE     READ WRITE CKSUM
        data1       ONLINE       0     0     0
          raidz1-0  ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0
            sde     ONLINE       0     0     0

errors: No known data errors

Waaaah.

Edit:
Ok dit is bizar, de binding van de pool /data1 lijkt weg te zijn en het lijkt net alsof hij de data gewoon naar een map genaamd data1 op / heeft geschreven. Mis ik nog een stap?

[ Voor 16% gewijzigd door Gonadan op 14-12-2014 16:53 ]

[Tadream]

Met die clone opties gaat het inderdaad een stuk sneller dan die gzip.
Dat is inderdaad meer bedoeld voor langdurige archief.
In ieder geval weer wat wijzer geworden kwa snapshot en archiveren enz.

En klopt het dan als je een gz bestand opzij hebt staan en je wilt eens een keer je pool opnieuw opbouwen, al dan niet met meer schijven/andere raidz formaat. Dat je dan die gz kan importeren/receiven?

[CurlyMo]

Tadream schreef op zondag 14 december 2014 @ 16:57:
Met die clone opties gaat het inderdaad een stuk sneller dan die gzip.
Dat is inderdaad meer bedoeld voor langdurige archief.
In ieder geval weer wat wijzer geworden kwa snapshot en archiveren enz.

Bedenk wel dat je via de clone manier bestanden exact 1 op 1 verplaatst. Gesimplificeerd gezegd is het dus een soort mv. Via de send/receive manier kan je dus wel je data bewerken zoals laten comprimeren. Die laatste kan je dus gesimplificeerd vergelijken met een cp. Dat is de reden dat een clone vrijwel direct gebeurd onafhankelijk van je bestandssysteem grootte terwijl een send / receive wel langer duurt met meer data.

En klopt het dan als je een gz bestand opzij hebt staan en je wilt eens een keer je pool opnieuw opbouwen, al dan niet met meer schijven/andere raidz formaat. Dat je dan die gz kan importeren/receiven?

Het is niet zo dat je zomaar met een zfs send backup even je pool indeling terug zet. Wil je dat echt helemaal goed doen dan zul je recursive snapshots moeten maken vanaf de root van je pool en ook vanaf die root een zfs send moeten doen. Het nadeel is dus dat je gelijk alle data van je pool mee kopieert. Dus niet alleen de indeling en instellingen. Ook is het afhankelijk van je zfs receive parameters of je data de eigenschappen van je doel krijgen of die van de bron behouden. In mijn voorbeeld heb je gezien dat je dus ongecomprimeerde data kan laten comprimeren door het te versturen naar een lz4 enabled zfs. Dit is op zich vrij onschuldig, maar pas op met bijvoorbeeld ACL's. Als je verkeerde zfs receive parameters opgeeft, dan kan het best zo zijn dat je al je permissie instellingen verliest, omdat ACL op je doel zfs niet goed staan ingesteld.

Dat laatste doe ik bijvoorbeeld alleen met de root pool. Deze wordt integraal verstuurd via zfs send/receive naar een tweetal backup pools. Van mijn data pool worden alleen de belangrijke bestandssystemen gekopieerd naar mijn backups.

Wil je echt een backup van ALLE instellingen. Sla dan de uitvoer van zfs get -t filesystem all op in een bestand. Dan zie je precies hoe je je zfs instellingen had staan.

[ Voor 19% gewijzigd door CurlyMo op 14-12-2014 17:32 ]

[Gonadan]

Gonadan schreef op zondag 14 december 2014 @ 16:13:
Ok dit is bizar, de binding van de pool /data1 lijkt weg te zijn en het lijkt net alsof hij de data gewoon naar een map genaamd data1 op / heeft geschreven. Mis ik nog een stap?

Helemaal niet bizar, die dist-upgrade die ik gedaan had heeft de ZoL PPA uitgecomment. Logisch want dat doet hij altijd met 3rd party sources bij een upgrade, maar daar krijg je wel de verkeerde mountall van.

Ofwel, ddrescue draait nu als een tiet.

[FireDrunk]

@gonadan, pas op met het gebruik van sda en sdb devices in je pool, dit kan echt snel fout gaan! Ik ben er absoluut geen voorstander van en ik kan je sterk aanraden dit om te zetten naar GPT partitielabels.

[Gonadan]

Kan dat bij een bestaande pool nog? Net zoals je fstab herzien naar UUID?

code:

/dev/sdb1: LABEL="data1" UUID="12970060002292513056" UUID_SUB="13376987617795757003" TYPE="zfs_member"
/dev/sdc1: LABEL="data1" UUID="12970060002292513056" UUID_SUB="3793098432994282835" TYPE="zfs_member"
/dev/sdd1: LABEL="data1" UUID="12970060002292513056" UUID_SUB="4589815474290222451" TYPE="zfs_member"
/dev/sde1: LABEL="data1" UUID="12970060002292513056" UUID_SUB="16512708479030980588" TYPE="zfs_member"

[ Voor 74% gewijzigd door Gonadan op 14-12-2014 21:46 ]

[CurlyMo]

Volgens mij alleen door een device uit de pool te halen en weer opnieuw toe te voegen met de nieuwe naam.

[FireDrunk]

Je kan even kijken of ZFS het ok vindt om diezelfde pool inderdaad op UUID te importeren

zfs unmount -a
zfs export data1
zfs import -d /dev/disk/by-id data1

Als dat goed gaat, is alles gewoon weer zoals het hoort, en zijn je filesystems meteen gemount.
Let op dat je even alle applicaties stopt die de pool gebruiken (zoals SabNZBd, SickBeard enzo)

@CurlyMo, wat jij bedoeld, is dat ZFS intern zijn metadata aanpast zodat de member disk een nieuw pad krijgt. Dat kan inderdaad, maar is volgens mij niet verplicht.

Als ik met zdb kijk, hebben de disks van mijn pool ook nog steeds als origineel pad, het pad onder BSD (/dev/gpt/[disk]). En dat werkt nog steeds prima onder ZoL.

[ Voor 32% gewijzigd door FireDrunk op 15-12-2014 08:33 ]

[Verwijderd]

Nadeel van hele disks is wel dat je nooit meer GPT partities kunt maken; en dus b.v. bij een overstap naar ZFSguru ook geen boot functionaliteit meer kunt gebruiken. Ook het encrypten via GELI (hardware accelerated encryptie via AES-NI) gaat dan niet meer. Ik kan dat niet aanraden; altijd GPT partities gebruiken.

[Gonadan]

Blijkbaar zijn de standaard tutorials leuk maar je kan feitelijk later opnieuw beginnen. Nergens wordt gerept over dergelijke zaken, ook niet over eenmalige zaken als ashift.

De optie van Firedrunk zal ik nog eens proberen, maar ik ga mijn pool niet weggooien en opnieuw bouwen. Heb al een schijf weten te redden, dus de ruimte heb ik nodig. Booten doe ik van een OS-disk, dus daar heb ik geen problemen mee voor zover ik weet.

[FireDrunk]

Hij heeft wel partities, maar geen idee welk type? Heb je MBR of GPT gebruikt Gonadan?
Als je GPT hebt, kan je achteraf nog gewoon labels toevoegen.

[Gonadan]

Ik heb helemaal niets gebruikt.

Gewoon kale disks en daar een zpool van gemaakt, zo moest dat volgens ZoL.
Als ik fdisk gebruik zie ik wel GPT geneuzel:

code:

   Device Boot      Start         End      Blocks   Id  System
/dev/sdb1               1  4294967295  2147483647+  ee  GPT

[FireDrunk]

Dus heb je wel partities... /dev/sdb1 betekend: de eerste partitie op de tweede harddisk (sda = SCSI disk A, SATA wordt gezien als SCSI...)

Welke handleiding heb je gevolgd?

_{GPT is btw helemaal geen geneuzel... , das erg belangrijk zelfs...}

[ Voor 19% gewijzigd door FireDrunk op 15-12-2014 09:25 ]

[Verwijderd]

Ik denk dat hij wel partities heeft gemaakt, maar bij het aanmaken van de pool de ruwe device node heeft gebruikt en vergeten is '1' achter de device node te typen. Dan gebruikt ZFS dus de ruwe device nodes. De partities worden nog wel gezien maar de data kan worden overschreven door ZFS. Dit is echt geen ideale situatie.

Juist om dit soort fouten te voorkomen is het gebruik van een ZFS web-interface enorm handig, die regelt dit allemaal automatisch en foolproof voor de gebruiker.

[Gonadan]

Tuurlijk zijn er partities, anders werkt een schijf niet, maar ik heb ze niet zelf bewust aangemaakt.

Wat ik gevolgd heb:
http://www.howtogeek.com/...ile-system-zfs-for-linux/

offtopic:
Geneuzel bedoel ik ook niet negatief, meer een kwestie van populaire spreektaal op de vroege ochtend.

@Ciber:
Nee ik heb geen partities gemaakt en de tutorial wees mij naar het opgeven van devices in plaats van partities.

[FireDrunk]

Goed, die handleiding mag in de prullenbak... Duidelijk door iemand gemaakt die niet snapt hoe device descriptors werken onder Linux...

Nogmaals: Pools aanmaken op SDA, SDB etc devices IS NIET VERSTANDIG! Verre van zelfs! Het is ontzettend gevoelig voor fouten!

Ik kan je toch echt aanraden om je pool opnieuw te maken...

[Verwijderd]

Gonadan schreef op maandag 15 december 2014 @ 09:30:
Tuurlijk zijn er partities, anders werkt een schijf niet

Dat is alleen onder Windows zo. Linux en BSD kunnen gewoon de ruwe device node gebruiken. Dat doet ZFS ook met jouw disks; want je ziet in de zpool status output gewoon 'sda' en 'sdb' staan ipv 'sda1' en 'sdb1'. Die 1 staat voor de 1e partitie.

Wat ik gevolgd heb:
http://www.howtogeek.com/...ile-system-zfs-for-linux/

Foute guide omdat deze expliciet een pool maakt op de ruwe device nodes, zonder partities.

@Ciber:

[FireDrunk]

offtopic:
Goh, CiPHER en ik zijn het eens

[Verwijderd]

offtopic:
Volgens mij zijn wij en vele anderen het op heel veel punten eens; alleen praten we veel vaker over de verschillen in opvattingen ipv de overeenkomsten.

[Gonadan]

Ok pretfuiken, is er dan een tutorial die wel geschikt is? Als ik nu opnieuw moet beginnen kost het mij een dag werk, maar is het nog te overzien. (moet weer ddrescue doen en alles inrichten)

Wat zijn de risico's van deze constructie?
Ik ben bekend met de wisselende deviceindicaties in het geval van meerdere controllers, maar bij mij zijn de indicaties al jaren ongewijzigd.

[FireDrunk]

The ZFS Storage Blog!

Die device letters zullen misschien al jaren niet gewijzigd zijn, maar dat is geen garantie dat ze niet *zullen* wijzigen. Stel je voor dat er een disk crasht... Jij zet netjes je server uit, trekt de schijf er uit, test hem in een andere pc, komt erachter dat het ding toch echt kapot is en denkt: Ok, RMA...
In de tussentijd wil je wel bij je data, dus zet je je Server weer aan, kan prima, want RAID-Z(2)...

Op *DAT* moment, veranderen dus je device descriptors, en kan ZFS de mist in gaan... Dat wil je op dat moment juist *NIET*...

[ Voor 76% gewijzigd door FireDrunk op 15-12-2014 09:40 ]

[Gonadan]

Hahaha had ik kunnen verwachten.

Dus nu zpool destroy en verder kan ik los met die link?

[FireDrunk]

Jup, als je geen belangrijke data op je pool hebt staan...

[Gonadan]

Jawel, maar dat moet dan maar opnieuw

Is er trouwens geen manier om data van een falende schijf te kopieren zonder er een hele ddrescue van te doen? Dat voelt namelijk als dubbel kopieren, alleen een gewone cp laat de meuk stallen als je pech hebt.

[FireDrunk]

Niet dat ik weet...

[Pantagruel]

Gonadan schreef op maandag 15 december 2014 @ 09:42:
Jawel, maar dat moet dan maar opnieuw

Is er trouwens geen manier om data van een falende schijf te kopieren zonder er een hele ddrescue van te doen? Dat voelt namelijk als dubbel kopieren, alleen een gewone cp laat de meuk stallen als je pech hebt.

Nope, geduld en koffie.

[Gonadan]

De laatste sector, kan je die gewoon default houden of moet je die ook op een specifiek punt alignen?

Pantagruel schreef op maandag 15 december 2014 @ 09:51:
Nope, geduld en koffie.

Hehe daar was ik al bang voor. Wat is eigenlijk het gedrag als je dan uiteindelijk het image gemount hebt en daar de bestanden af kopieert? Op de schijf zelf zal hij vertragen en/of hangen vanwege leesfouten als een bestand beschadigd is, geeft het kopieren met een image dan meteen een fout of slaat hij die gewoon over?

[ Voor 69% gewijzigd door Gonadan op 15-12-2014 10:04 ]

[FireDrunk]

Mag gewoon laatste sector zijn, mits je je extreem wil beveiligen tegen het miniscule risico dat een nieuwe schijf een paar bytes kleiner is.

[Verwijderd]

Ik snap dat hele ddrescue niet. En hoezo praten jullie over de laatste sector?

Als je het goed wilt doen maak je de GPT partitie minimaal 1MiB kleiner dan de schijf. Dan heb je altijd nog ruimte voor hardware encryptie onder BSD OS of andere zaken, en bescherm je inderdaad ook tegen net wat kleinere disks. Waarom zou je dat níet doen? Die 1MiB mis je toch niet.

[FireDrunk]

Oh nee, maar er is tegenwoordig een conventie tussen HD fabrikanten om dat probleem te verhelpen. Ze hebben officeel afgesproken dat ze de groottes op elkaar afstemmen.

[Gonadan]

Zo dan? Moet ik nu nog iets doen of kan ik hem nu echt gaan gebruiken?

code:

  pool: data1
 state: ONLINE
  scan: none requested
config:

        NAME                         STATE     READ WRITE CKSUM
        data1                        ONLINE       0     0     0
          raidz1-0                   ONLINE       0     0     0
            DATA1-B-WD-WCC4NDPT01JV  ONLINE       0     0     0
            DATA1-C-WD-WCC4NHDR8C5E  ONLINE       0     0     0
            DATA1-D-WD-WCC4NKCPS5PY  ONLINE       0     0     0
            DATA1-E-WD-WCC4NCCAUNUV  ONLINE       0     0     0

errors: No known data errors

@Cipher: wat snap je niet aan ddrescue? Jij hebt zelf toch dd gebruikt dacht ik ergens te lezen?

[FireDrunk]

Keurig!

[Verwijderd]

Ik snap niet zo goed waarvoor je ddrescue gebruikt. Wat je te maken hebt met de laatste sector enz.

De juiste procedure lijkt mij:
1. data backuppen die je al op de pool had staan.
2. pool destroyen
3. partities aanmaken met GPT, waarbij je de partitie minimaal 1MiB kleiner maakt dan de volledige capaciteit, en ook pas op 1MiB offset laat beginnen zodat je een boot partitie aan het begin kunt plaatsen.
4. de ZFS pool aanmaakt op de grote GPT partitie

Ik vermoed dat je nu een GPT partitie hebt die geen ruimte overlaat. Zou je ooit naar een ander OS willen en encryptie oid willen gebruiken, of van willen booten, is dat niet handig. Weet je 100% zeker dat je bij Linux blijft en niets anders met de disks/pools gaat doen, dan is het prima zo. Maar toch jammer dat je twee megabyte niet opoffert om in de toekomst veel flexibeler te zijn met opties enz.

[Gonadan]

Jullie moeten echt samen een grote blog gaan schrijven waar alle overwegingen in staan. Het wordt een iteratief proces zo.

Overigens heb ik de door Firedruk aangegeven +2M ruimte aan het begin over gelaten, dus ze zitten niet ramvol. Volgens gdisk was er iets van 3M vrij op de disk.

ddrescue gebruik ik voor de schijven die gefaald zijn. Daar staat een hoop gedownload materiaal op. Absoluut niet belangrijk genoeg maar alles wat ik niet opnieuw hoef te downloaden is weer meegenomen. Dus daar wil ik hem best even op de achtergrond voor laten draaien. De reden dat ik ddrescue gebruik is omdat als je de schijf mount en de beschadigde sectoren wilt lezen het hele systeem dat kut vindt, en als je ddrescue gebruikt hij dat gewoon losstaand uitvoert zonder impact.

[ Voor 45% gewijzigd door Gonadan op 15-12-2014 10:42 ]

[Verwijderd]

2MiB in het begin vrij is prima; 1MiB is beter omdat dat de algemene conventie voor alignment/offset is.

Maar de ruimte op het einde is ook belangrijk, vooral als je ooit naar BSD wilt migreren. Zou je hardware encryptie willen gebruiken moet er een sector aan het einde van de disk worden geschreven. Als je partitie tot aan het einde loopt, heb je die ruimte niet meer. Voor elke GEOM laag is er één sector nodig. Daarom is het goed om minimaal 1MiB vrij te laten aan het einde van de disk.

Dit is ook hoe ZFSguru de partities aanmaakt. Om die reden adviseer ik soms om de partities (en pool) met ZFSguru aan te maken en dan pas naar Linux te verhuizen. Dan weet je zeker dat alles goed ingesteld staat. Maar kan natuurlijk ook gewoon in Linux, maar dan moet je al dit soort dingen maar net weten.

[Wiebeltje]

FireDrunk schreef op maandag 15 december 2014 @ 08:31:
Je kan even kijken of ZFS het ok vindt om diezelfde pool inderdaad op UUID te importeren

zfs unmount -a
zfs export data1
zfs import -d /dev/disk/by-id data1

Als dat goed gaat, is alles gewoon weer zoals het hoort, en zijn je filesystems meteen gemount.
Let op dat je even alle applicaties stopt die de pool gebruiken (zoals SabNZBd, SickBeard enzo)

Tnx, sinds een update van ZFS laatst waren mijn disks gemount met sdb / sdc. Nu is het weer fatsoenlijk met de UUID's. Wel even een correctie, die import / export moeten zpool zijn.

zfs unmount -a
zpool export data1
zpool import -d /dev/disk/by-id data1

FireDrunk schreef op maandag 15 december 2014 @ 09:13:
Hij heeft wel partities, maar geen idee welk type? Heb je MBR of GPT gebruikt Gonadan?
Als je GPT hebt, kan je achteraf nog gewoon labels toevoegen.

Kun je die labels ook nog terug laten komen onder "zpool status". Ik heb wel labels maar ik zie in de status dus die ID's.

Ik heb overigens ook nog altijd de volgende melding:

Upgrade the pool using 'zpool upgrade'.  Once this is done, the
pool will no longer be accessible on software that does not support
feature flags.

Ik weet dat het geen kwaad kan maar ik zou hem toch graag weg hebben. Hoe kan ik upgraden zonder dat ik compatibility met FreeBSD verlies (draai nu Ubuntu + ZOL)? Ik weet dat het hier vaker voorbij gekomen is maar het is me nooit helemaal duidelijk geworden... Ik ben bang dat als ik een normale "zpool upgrade" doe er allerlei features flags aan gaan waarna ik compatibility verlies.

[ Voor 12% gewijzigd door Wiebeltje op 15-12-2014 10:58 ]

[FireDrunk]

Check, goed dat je even aanwijst dat het zpool moet zijn ipv zfs ik slaap nog

Je kan de labels naar voren krijgen als je de pool even exporteert, en daarna weer importeert met:

zpool import -d /dev/disk/by-partlabel/ [poolnaam]