Het grote DIY RAID NAS topic deel 3

[thibautb]

Weet er iemand toevallig waar ik binnen eu/uk een Norcotek RPC-4224 kan vinden of iets dat er ongeveer op lijkt dus met 24 bays en liefst onder de 400 euro en ook atx psu. Ri-vier heeft er ook wel ongeveer zo een maar die is pas tegen begin mei terug te koop en de 3u 16 bays zijn ook niet zo handig van hun want 2u psu en natuurlijk dan maar 16 bays ipv 24 voor 320.
Bedankt!

[BartNL]

in de UK X-Case RM 424 met 24 bays en na bestelling binnen 2-3 dagen op de deurmat. Is inclusief verzendkosten 355 GBP is ongeveer €485,- en dan krijg je de rails er bij. Zie ook YouTube: RM 424 Gen II 24 Bay NAS Chassis

Door huidige euro koers zijn prijzen hoger dan een jaar geleden. Toen zou dezelfde 355 GBP omgerekend €420,- zijn geweest

[ Voor 22% gewijzigd door BartNL op 02-04-2015 17:35 ]

[Chilco]

Hoop dat dit het juiste forum is voor mijn vraag, vind het een beetje onnodig om hier een nieuw topic voor aan te maken. Ik ben van plan om met de huidige hardware wat ik thuis heb liggen een freenas te maken.
Nu heb ik deze keuze uit twee setups:
http://www.asus.com/Motherboards/M4A785DM_PRO/overview/
in combinatie met amd x2 6000+ 89watt tdp

of

http://www.asus.com/Motherboards/P5KC/overview/
in combinatie met een e8600 en een ati hd 5450

Vind het een beetje een lastige keuze, de amd setup heeft een moderner moederbord (meer sata aansluitingen en raid mogelijkheden) terwijl de intel setup sneller is. Het verbruik lijkt mij in het voordeel van de amd setup als ik cpuboss moet geloven, of is het mogelijk om na de installatie van freenas de videokaart te verwijderen ?

Welke setup zouden jullie kiezen ?

[player-x]

Chilco schreef op donderdag 02 april 2015 @ 17:56:
Nu heb ik deze keuze uit twee setups:

De E8600 is de beste keuze, daar ik geloof dat die zuiniger is dan de X2 in idle verbruik, voor de rest maakt het niet erg veel uit.

Maar om het absoluut zeker te weten kan je de mobo aan een verbruiksmeter hangen, om te zien welke het zuinigst is tijdens idle.

Vind het een beetje een lastige keuze, de amd setup heeft een moderner moederbord (meer sata aansluitingen en raid mogelijkheden)

Nee hoor ze hebben beide 5+1 (e)SATA alleen zit die bij het Intel bord een beetje raar voor het PCIe slot.

terwijl de intel setup sneller is. Het verbruik lijkt mij in het voordeel van de amd setup als ik cpuboss moet geloven, of is het mogelijk om na de installatie van freenas de videokaart te verwijderen ?

Ja dat gaat prima.

Welke setup zouden jullie kiezen ?

Intel

[Q]

jacovn schreef op donderdag 02 april 2015 @ 10:15:
Q, nee dat had ik niet gedaan, maar net even getest:

BS=1M is block/request size, die zou ik dus max 1M houden en een count 50000 minimaal doen, zodat je niet loopt te cachen op de een of andere manier.

600 MB/s zou al mooi zijn en uitsluiten dat je netwerk zelf niet een issue is.

Iperf snap ik niet helemaal met al die extra opties, de -t 10 lijkt me wel kort, maakt het nog uit als je het 60-300 seconden laat lopen? wat zegt dstat gedurende de iperf test? Die waarden lijken wel ok, doe ook eens de test met verkeer beide kanten op -d of -D meen ik.

[Darkstylo]

Hallo allemaal,

Wellicht kunnen jullie mij helpen, ik wil een soort-achtige NAS met daarop een Webserver, Plex, Couchpotato, Sickbeard, File server, Backup, Teamspeak/Mumble en wat andere kleine zaken.

Plex moet 3-4 transcoding streams concurrent aan kunnen. Op dit moment draai ik een dedicated back bij online.net, die overigens zwaar overkill is 2x E5-2620v2, 128GB DDR ECC. Toen destijds een aanbieding kunnen regelen en was de server meer voor test doeleinden.

Nu dat ik beschik over een glas verbinding thuis, wil ik alles gewoon thuis draaien.
Server zal draaien op Ubuntu op een SSD
Een aantal disks in een ZFS pool (RaidZ of RaidZ2) waarschijnelijk ga ik beginnen met 3x 3TB.

Zelf had ik dit in gedachte, puur vanwege ECC en ZFS discussie.

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1241 v3 Tray	€ 294,50	€ 294,50
1	Supermicro X10SL7-F	€ 272,-	€ 272,-
1	Fractal Design Node 804	€ 94,95	€ 94,95
1	Crucial CT2KIT102472BD160B	€ 159,50	€ 159,50
1	Seasonic G-series 450 watt	€ 78,50	€ 78,50
1	Crucial MX100 128GB	€ 65,95	€ 65,95
Bekijk collectie Importeer producten		Totaal	€ 965,40

Zijn er mensen die problemen hebben gehad met ZFS en non ECC memory?

[FREAKJAM]

Ik draai bijna dezelfde setup, alleen dan moet een 1230v3 cpu en 6 schijven (6x3TB).
In principe zou je zelfs uit de voeten moeten kunnen met een voeding van 360 watt (zie mijn signature).

Ik heb zelf geen ervaring met het draaien van ZFS zonder ECC. Ik gebruik zelf gewoon ECC RAM.

[MTDjassen]

Darkstylo schreef op vrijdag 03 april 2015 @ 11:09:
(...)

Zijn er mensen die problemen hebben gehad met ZFS en non ECC memory?

Eindeloze discussie in 3... 2... 1...

[player-x]

Darkstylo schreef op vrijdag 03 april 2015 @ 11:09:
Zijn er mensen die problemen hebben gehad met ZFS en non ECC memory?

Er zijn twee stromingen, ook hier, persoonlijk denk ik dat ECC zwaar is over overrated, ja het is een plus, maar alleen voor systemen die gebruikt worden voor absoluut kritieke data.

En imho is de gebruikte argumenten voor ECC overdreven zijn, en er letterlijk nergens harde cijfers zijn die die stelling echt ondersteunen.

Een imho betere analogie zou zijn, ZFS voegde gordels en een airbag toe aan het file systeem, vergeleken met NTFS, ECC voegt daar nog eens zij-airbags aan toe, of dat je dat 100~300 euro extra waard is, is aan je zelf, ik vind het persoonlijk overdreven voor een normale thuis server.

Bouw je een bedrijfsserver, dan zou ik zeker ECC gebruiken, daar dan de in verhouding geringe meer prijs voor bedrijven niet opweegt tegen over data corruptie, daar een bit flip daar vaker grotere potentiële gevolgen hebben bij bedrijfsdata, daarnaast verblijft er langduriger veel cache data in geheugen als er bv een database op ZFS draait.

Voor een systeem met voornamelijk video files is een bit flip niet echt een probleem, daar het meestal zal lijden tot een kleine korte kleur of beeld verstoring of zo.

En er is een helle simpele argument dat het belang van ECC voor thuis gebruik onderuit haalt, zelfs bij bedrijven wordt er geen ECC gebruikt in desktops, terwijl de data die opgeslagen wordt op het ZFS systeem, 99% meer tijd in dat type NON-ECC geheugen en het NTFS file systeem wordt gehouden en bewerkt, dan tijdens de korte tijd dat het door het ECC geheugen gaat van je/de server gaat tijdens verwerking voor opslag.

Non-ECC ZFS is vele malen veiliger voor data integriteit, dan welke ext4 of NTSF file systeem van een NAS of server met ECC, daar ZFS zich zelf controleert, en voor ext4 en NTSF wordt het wel als normaal gezien dat er geen ECC geheugen gebruikt wordt.

Denk dat deze auto analogie redelijk op gaat.

• FAT - een jaren 60 auto zonder gordels.
• NTFS & ext4 - een jaren 70 auto met een heup gordeltje
• ZFS - een moderne auto met ABS, 3 punts gordel en airbags.
• ZFS + ECC - voegt daar nog eens zij impact airbags aan toe.

Ik denk dat het een redelijke analogie is.

Maar een ding boven alles is zeker, voor het gebruik van ECC in je server geld iig, baat het niet schaad het niet, is veiligheid een top prio, koop gewoon ECC en je ben zeker weer iets veiliger bezig.

Ik zelf draai met opstarten een geheugen test, en dat is goed genoeg voor mij.

[Darkstylo]

bedankt voor de opheldering!

[ Voor 97% gewijzigd door Verwijderd op 03-04-2015 14:28 . Reden: niet onnodig quoten aub ]

[jacovn]

Q schreef op donderdag 02 april 2015 @ 23:14:
[...]


BS=1M is block/request size, die zou ik dus max 1M houden en een count 50000 minimaal doen, zodat je niet loopt te cachen op de een of andere manier.

600 MB/s zou al mooi zijn en uitsluiten dat je netwerk zelf niet een issue is.

Iperf snap ik niet helemaal met al die extra opties, de -t 10 lijkt me wel kort, maakt het nog uit als je het 60-300 seconden laat lopen? wat zegt dstat gedurende de iperf test? Die waarden lijken wel ok, doe ook eens de test met verkeer beide kanten op -d of -D meen ik.

Dat statement wat jij gegeven had voor op de host om verkeer te acepteren doet het niet voor mij:

code:

[root@zfsguru3 /home/ssh]# nc -l -p 1234 | dd of=/dev/null bs=1M
usage: nc [-46DdEhklNnrStUuvz] [-e policy] [-I length] [-i interval] [-O length]
          [-P proxy_username] [-p source_port] [-s source] [-T ToS]
          [-V rtable] [-w timeout] [-X proxy_protocol]
          [-x proxy_address[:port]] [destination] [port]
0+0 records in
0+0 records out
0 bytes transferred in 0.000297 secs (0 bytes/sec)

Het maakt niet uit of ik de andere kant eerder of later opstart:: dd if=/dev/zero bs=1M | nc 192.168.3.153 1234


Als ik de ontvangst kan aanpas naar: nc -v -l 1234 >/dev/null dan werkt het wel.

code:

[root@zfsguru /home/ssh]# dd if=/dev/zero bs=1M | nc 192.168.3.153 1234
^C12025+0 records in
12024+0 records out
12608077824 bytes transferred in 75.264020 secs (167517996 bytes/sec)

Dat lijkt wel weer meer op de 150 MB/sec


Als ik iperf draai met mijn settings maar dan 60 seconden krijg ik:

code:

[  3]  0.0-60.0 sec  65881 MBytes  1098 MBytes/sec

[Chilco]

player-x schreef op donderdag 02 april 2015 @ 18:33:
Intel

Bedankt voor je reactie, dan ga ik het een keer proberen met de intel setup

[Q]

De argumenten om thuis geen ECC-geheugen toe te passen zijn 100% hetzelfde om geen ZFS toe te passen. De risico's zijn klein voor thuis. En ik denk dat dit waar is, het is allemaal geen halszaak, maar het risico op rot geheugen of rotte data van je schijven is er wel, het is niet nul. Aan jou de keuze.

Aan de ene kant beschermt ZFS je tegen het risico van bitrot van harde schijven, een zeer klein risico, maar aan de andere kant krijg je het risico terug dat je hele pool verloren kan gaan als je non-ECC geheugen rot raakt, wat spontaan kan gebeuren. Dit heeft ook gevolgen voor legacy file systems, maar praktisch gezien kun je - als het moet - vaak dan nog wel data redden of dingen doen, met ZFS is het dan echt over (alle data weg).

Laatst zag ik nog een post op Reddit over iemand die een test systeem in elkaar had gezet, met pool en toen door brak geheugen de pool kwijt raakte. Voor die persoon weer het bewijs om geen non-ecc geheugen te gebruiken, die dit zeker had voorkomen (het systeem halt bij rotte bits als je ECC toepast en er wordt dus geen data on-disk vermangeld). Overigens ging het wel om nieuw geheugen dat rot bleek, maar dat maakt voor het principe niets uit.

player-x schreef op vrijdag 03 april 2015 @ 12:43:
[...]
En er is een helle simpele argument dat het belang van ECC voor thuis gebruik onderuit haalt, zelfs bij bedrijven wordt er geen ECC gebruikt in desktops, terwijl de data die opgeslagen wordt op het ZFS systeem, 99% meer tijd in dat type NON-ECC geheugen en het NTFS file systeem wordt gehouden en bewerkt, dan tijdens de korte tijd dat het door het ECC geheugen gaat van je/de server gaat tijdens verwerking voor opslag.

Het argument is onjuist en geeft een verkeerde voorstelling van zaken. Als een bedrijf 100 desktops heeft en eentje doet gek door rot geheugen, dan worden misschien een paar bestanden gemangeld van die gebruiker, maar een restore van backup lost dat wel op, de impact is heel erg beperkt. De rest van het bedrijf draait door en een fractie van de data wordt getroffen.

Zou de server dit overkomen, dan wordt alle data die wordt gemanipuleerd vermalen door rot geheugen en is er kans dat het hele filesystem wordt verkloot (alle data weg). In jouw thuis situatie is jouw NAS analoog aan de server bij het bedrijf. Dat bedrijven ECC geheugen gebruiken in hun servers is juist een heel goed argument om dat thuis op kleine schaal ook te overwegen voor je eigen server.

Of je ook echt thuis met ECC geheugen aan de gang wilt, is helemaal aan jou. Jouw data, jouw geld, jouw risico. Het risico is niet groot, maar niet nul.

Non-ECC ZFS is vele malen veiliger voor data integriteit, dan welke ext4 of NTSF file systeem van een NAS of server met ECC, daar ZFS zich zelf controleert, en voor ext4 en NTSF wordt het wel als normaal gezien dat er geen ECC geheugen gebruikt wordt.

Dat laatste komt omdat bedrijven die NTFS/EXT4 toepassen, ZFS-style parity bescherming kopen via hun hardware. in SAS schijven worden grotere sectoren met parity toegepast. Denk dus niet dat bedrijven altijd maar een soort van risico namen met NTFS/EXT4, zij lossen/losten dat risico van data integriteit anders op.

ZFS is dus beter geschikt om met de minder betrouwbare consumenten hardware om te gaan, zeker een plus voor thuis. Maar net zo min dat ECC een soort van halszaak is, is ZFS dat ook niet voor thuis.

Kijk maar in het 20TB+ topic, meer mensen die ECC toepassen dan ZFS .

Ik zelf draai met opstarten een geheugen test, en dat is goed genoeg voor mij.

Je bent waarschijnlijk de enige ter wereld die dat doet, als je niet verwijst naar de standaard (lange) bios test van het geheugen.

[BartNL]

@Q
had het niet beter kunnen verwoorden

[BartNL]

Chilco schreef op vrijdag 03 april 2015 @ 17:13:
[...]Bedankt voor je reactie, dan ga ik het een keer proberen met de intel setup

ik zou de AMD setup overwegen vanwege de ondersteuning van ECC geheugen

[player-x]

Q schreef op vrijdag 03 april 2015 @ 19:54:
De argumenten om thuis geen ECC-geheugen toe te passen zijn 100% hetzelfde om geen ZFS toe te passen. De risico's zijn klein voor thuis.

Een groot verschil, ECC kost veel geld, ZFS is gratis.

Dit heeft ook gevolgen voor legacy file systems, maar praktisch gezien kun je - als het moet - vaak dan nog wel data redden of dingen doen, met ZFS is het dan echt over (alle data weg).

Vraag me af wie er vaker last heeft van een verloren pool/array, ZFS of legacy raid5/6, en hoe vaak ECC daar zelfs een rol in speelt.

Want wederom is het risico van bit-flips nergens met harde cijfers wordt bepaald, ik heb iig nergens harde cijfers gevonden, dus jij gaat uit van een onbekend risico, en zegt dat het een reëel probleem is, ik persoonlijk wil eerst wel eens harde cijfers zien om die aanname voor een feit te zien.

Laatst zag ik nog een post op Reddit over iemand die een test systeem in elkaar had gezet, met pool en toen door brak geheugen de pool kwijt raakte. Voor die persoon weer het bewijs om geen non-ecc geheugen te gebruiken, die dit zeker had voorkomen (het systeem halt bij rotte bits als je ECC toepast en er wordt dus geen data on-disk vermangeld). Overigens ging het wel om nieuw geheugen dat rot bleek, maar dat maakt voor het principe niets uit.

Er bestaat ook een kans dat ik morgen mijn huis door bliksem geraakt wordt, is voor mij geen reden om op mijn rijtjeshuis een bliksem afleider te monteren.

Onzinnig voorbeeld imho, maar het toont mij veel meer aan dat je dom bezig bent als je geen 24 of 48 uur burn-in test doet van je hele systeem, de gratis versie doet alles wat je wilt testten.

Het argument is onjuist en geeft een verkeerde voorstelling van zaken. Als een bedrijf 100 desktops heeft en eentje doet gek door rot geheugen, dan worden misschien een paar bestanden gemangeld van die gebruiker, maar een restore van backup lost dat wel op, de impact is heel erg beperkt. De rest van het bedrijf draait door en een fractie van de data wordt getroffen.

Goed tegen argument, ik geef je die.

Zou de server dit overkomen, dan wordt alle data die wordt gemanipuleerd vermalen door rot geheugen en is er kans dat het hele filesystem wordt verkloot (alle data weg).

Lang voor dat, geeft normaal gesproken ZFS al lang een waarschuwing, dat er problemen zijn met het file systeem.

In jouw thuis situatie is jouw NAS analoog aan de server bij het bedrijf. Dat bedrijven ECC geheugen gebruiken in hun servers is juist een heel goed argument om dat thuis op kleine schaal ook te overwegen voor je eigen server.

Nee hoor, want hier geldt een beetje het tegenovergestelde van je bedrijf met 100 desktops voorbeeld, voor een bedrijf is het een beperkte investering om ECC in een server te stoppen om niet een probleem te zijn voor meerdere gebruikers.

Bij een thuis server geldt dat veel minder.

Of je ook echt thuis met ECC geheugen aan de gang wilt, is helemaal aan jou. Jouw data, jouw geld, jouw risico. Het risico is niet groot, maar niet nul.

De vraag is puur is het de extra 100~300 euro waard voor een simpele thuis server, ik denk onder de streep voor de meeste mensen, nee, iig als ze zich niet gek laten maken.

Dat laatste komt omdat bedrijven die NTFS/EXT4 toepassen, ZFS-style parity bescherming kopen via hun hardware. in SAS schijven worden grotere sectoren met parity toegepast. Denk dus niet dat bedrijven altijd maar een soort van risico namen met NTFS/EXT4, zij lossen/losten dat risico van data integriteit anders op.

Dat geld alleen maar voor echt grote bedrijven, de gemiddelde admin koopt gewoon standaard bedrijfs harde schijven, een stap beter dan de Green line, maar zeker ook weer geen exotische oplossingen.

ZFS is dus beter geschikt om met de minder betrouwbare consumenten hardware om te gaan, zeker een plus voor thuis. Maar net zo min dat ECC een soort van halszaak is, is ZFS dat ook niet voor thuis.

Wederom ECC kost geld, ZFS is een stuk veiliger zonder dat het geld kost, is voor de meeste mensen, die het aandurven om ZFS te gebruiken een no-brainer

Kijk maar in het 20TB+ topic, meer mensen die ECC toepassen dan ZFS .

Een groot deel heeft dat gedaan omdat ze zich doods bang hebben laten maken door "merkloze condooms kopen of een chinese tweedehandsparachute'' argumenten, en imho redelijk vaak onterecht.

Je bent waarschijnlijk de enige ter wereld die dat doet, als je niet verwijst naar de standaard (lange) bios test van het geheugen.

Heb op mijn offline server met ZFS, die 1x per week opstart, gewoon MemTest86 opgenomen in de batch file die ook de backup's maakt, en het resultaat wordt weggeschreven op de desktop van mijn gewone server, en op mijn gewone live server (2012R2), heb ik 1x per maand een event aangemaakt die MemTest86 opstart, niet zo moeilijk om te doen hoor.

Dat ik een hekel heb aan (imho) onnodig geld uit geven, betekend niet dat ik geen extra veiligheid in mijn systeem inbouw als het gratis is.

[BartNL]

player-x schreef op vrijdag 03 april 2015 @ 21:48:
[...]
De vraag is puur is het de extra 100~300 euro waard voor een simpele thuis server, ik denk onder de streep voor de meeste mensen, nee, iig als ze zich niet gek laten maken.

Voor 8GB thuisserver bijvoorbeeld gebaseerd op het AMD moederbord dat jij een paar posts hierboven niet zo ziet zitten is het prijsverschil eerder €50. Persoonlijk vind het wel verantwoord om bijvoorbeeld die €50 uit te geven aan ECC geheugen wanneer je een fileserver van €1000 in elkaar draait.

[player-x]

BartNL schreef op vrijdag 03 april 2015 @ 23:12:
Voor 8GB thuisserver bijvoorbeeld gebaseerd op het AMD moederbord dat jij een paar posts hierboven niet zo ziet zitten is het prijsverschil eerder €50. Persoonlijk vind het wel verantwoord om bijvoorbeeld die €50 uit te geven aan ECC geheugen wanneer je een fileserver van €1000 in elkaar draait.

Als je het AMD systeem gebruikt ben je 75 euro meer kwijt voor 8GB DDR2 ECC geheugen, plus extra verbruik, want die CPUs waren niet echt super zuinig in idle.

AM3(+) moederborden kosten minimaal 100 euro en er is veel minder keuze, FM2 ondersteund geen ECC, daarnaast is het idle verbruik hoger, en er is ook geen onboard video.

Dus zelfs als je met AMD oplossing gaat ben je ook ongeveer 100 euro extra kwijt.

offtopic:
btw, ik heb niks tegen ECC, zeer waarschijnlijk ga ik het zelf ook weer gebruiken als ik een nieuwe mobo haal, maar dat word een systeem voorbereid op 100TB+ en zal gebruikt worden door zo een 15 gebruikers, en door de kosten te verdelen over 4 gezinnen, en het meer intensief gebruik, hebben we wat meer marge in het budget.

[Q]

player-x schreef op vrijdag 03 april 2015 @ 21:48:
[...]

Een groot verschil, ECC kost veel geld, ZFS is gratis.

Sorry maar waarom ga jij voor andere mensen bepalen wat veel geld is? Of wat 'duur' is? Zou het niet eerlijker zijn om mensen dat zelf te laten bepalen?

Dat ZFS gratis is, maakt conceptueel helemaal niets uit. De drempel om ZFS toe te passen is laag qua kosten, maar iemand die geen Linux/BSD guru is en wel veel Windows ervaring heeft, en thuis gewoon rust wil, kan om die redenen best kiezen om gewoon een Windows machine neer te zetten. Het risico waar ZFS tegen beschermt is ook weer niet zo groot. Er speelt veel meer mee.

Ik beweer zelfs puur op basis van logisch denken dat ZFS tegen een risico beschermt wat kleiner is dan rot RAM geheugen. Juist omdat er al heel veel error correctie zit in harde schijven en je het risico van een URE thuis zeer waarschijnlijk nooit gaat meemaken.

Vraag me af wie er vaker last heeft van een verloren pool/array, ZFS of legacy raid5/6, en hoe vaak ECC daar zelfs een rol in speelt. Want wederom is het risico van bit-flips nergens met harde cijfers wordt bepaald, ik heb iig nergens harde cijfers gevonden, dus jij gaat uit van een onbekend risico, en zegt dat het een reëel probleem is, ik persoonlijk wil eerst wel eens harde cijfers zien om die aanname voor een feit te zien.

Het gaat niet om de cijfers, dan mis je het punt. Conceptueel weet je dat rot geheugen resulteert in onzin data op schijf en ZFS kan daar niet tegen. Zoals geen enkel file system daar tegen kan. Wederom verwijs ik naar de welbekende paper. En dan poef, je pool niet meer te importeren. Big fun!

Er bestaat ook een kans dat ik morgen mijn huis door bliksem geraakt wordt, is voor mij geen reden om op mijn rijtjeshuis een bliksem afleider te monteren.

Maar als die bliksem afleider gratis is, dan doe je opeens wel die moeite? Dat snap ik niet zo.

Overigens doe je weer met deze brakke analogie alsof het risico waar ECC geheugen tegen beschermt verwaarloosbaar is, en dat is niet waar. Dat mensen het risico wille nemen om geld te besparen, prima.

Onzinnig voorbeeld imho, maar het toont mij veel meer aan dat je dom bezig bent als je geen 24 of 48 uur burn-in test doet van je hele systeem, de gratis versie doet alles wat je wilt testten.

Een zinnig voorbeeld, want nogmaals, het toont wederom aan dat rot geheugen een pool killed. Dat dit in dit geval bij installatie gebeurde, doet hier niets aan af.

Een burn-in test is zeker verstandig en heb ik ook gedaan met mijn systeem. Maar resultaten uit het verleden bieden geen garantie voor de toekomst. Het kan zomaar spontaan mis gaan. Die kans is thuis kleiner dan op de schaal van Amazon, Microsoft en Google, maar dat jij thuis de dans gaat ontspringen is niet gegeven. Gaat het mis, dan behoed ECC geheugen je voor data corruptie.

Lang voor dat, geeft normaal gesproken ZFS al lang een waarschuwing, dat er problemen zijn met het file systeem.

Tegen de tijd dat je 's ochtends wakker wordt of terug van het werk komt is je pool al stuk toen die automatische backup liep. Zinloos wat mij betreft: put dempen als kalf verdronken is. ECC is je enige echte bescherming. Misschien je systeem meteen een halt geven als een error wordt geconstateerd, maar ook dat kan het einde betekenen. En wie van de DIY NAS mensen die hier posten zie je dat doen?

En wederom het argument wat ik al meerdere keren heb gebruikt: de DIY NAS bouwers hier die denken er niet eens aan om de boel zo op te zetten dat ze mails ontvangen als er dingen stuk gaan. Dan is de aardlekschakelaar-style beveiliging van ECC een heel stuk 'gebruiksvriendelijker'. Dan hou je rekening met het publiek hier.

De vraag is puur is het de extra 100~300 euro waard voor een simpele thuis server, ik denk onder de streep voor de meeste mensen, nee, iig als ze zich niet gek laten maken.

Weer praat je met termen als 'gek laten maken', dus alsof je gek bent als je ECC koopt, en dat is super unfair - gegeven de feiten - om zo over ECC te praten, wetende dat het hele bedrijfsleven op ECC draait.
Praten over de risico's van ECC afwimpelen als 'gek laten maken' is ongefundeerde, onjuiste rethoriek die andere mensen de keuze ontneemt om zelf een afgewogen beslissing te nemen. Jij neemt die voor hen en dat vind ik onjuist.

Het punt is dat ik vind dat ik in mijn schrijven een eerlijke keuze biedt aan de DIY NAS bouwer, waarbij ik de informatie geef en de bouwer zelf mag kiezen en een afweging kan maken. Jij maakt die afweging voor de DIY NAS bouwer en dat vind ik niet fair. Jij bent niet de gene die voor mensen bepaalt wat hun data waard is. En wat 'veel geld' is. Dat is allemaal persoonlijk en relatief. Laat mensen zelf kiezen. Er zijn zat mensen die denken 'pfff' 150 euro, nobrainer, doen. Machine gaat 5 jaar mee, voor 30 euro per jaar ben ik klaar, het gaat nergens over. Of inderdaad: voor mij is 150 echt teveel geld voor het risico, ik doe het niet. Maar laat mensen ZELF de keuze maken.

Jij doet in je schrijven hierboven weer voorkomen alsof mensen die ECC toepassen spoken zien die niet bestaan, dat dit 'zwaar overdreven' is en dat het eigenlijk allemaal niet nodig is. En dat is niet fair. Daarmee ontneem je mensen een keuze op basis van afgewogen informatie, waarom zou jij die afweging voor hen maken?

Voor mij zou het al een heel ander verhaal zijn als het mis gaat door dat ik een risico heb genomen op basis van een eigen afweging, dan dat ik een forum poster vertrouw die roept dat het thuis niet nodig is. In dat laatste geval zou ik mij goed genaaid voelen.

Dat geld alleen maar voor echt grote bedrijven, de gemiddelde admin koopt gewoon standaard bedrijfs harde schijven, een stap beter dan de Green line, maar zeker ook weer geen exotische oplossingen.

Ik weet niet precies wat 'standaard bedrijfs harde schijven zijn'. Maar voor de bedrijven die geen HP of DELL server draaien met SAS spul is het risico ook weer kleiner. Wij hebben een schijf of honderd, dan praat je weer over andere risico's.

Wederom ECC kost geld, ZFS is een stuk veiliger zonder dat het geld kost, is voor de meeste mensen, die het aandurven om ZFS te gebruiken een no-brainer

Jij kijkt sec naar geld, maar dat is dus niet de enige factor die mee speelt, en ZFS is dus niet gratis want je krijgt er een bepaald risico voor terug.

Een groot deel heeft dat gedaan omdat ze zich doods bang hebben laten maken door "merkloze condooms kopen of een chinese tweedehandsparachute'' argumenten, en imho redelijk vaak onterecht.

Tja, dit wordt een soort van cirkel redenering nu. Je projecteert je eigen visie retroactief op hun keuzes.

Heb op mijn offline server met ZFS, die 1x per week opstart, gewoon MemTest86 opgenomen in de batch file die ook de backup's maakt, en het resultaat wordt weggeschreven op de desktop van mijn gewone server, en op mijn gewone live server (2012R2), heb ik 1x per maand een event aangemaakt die MemTest86 opstart, niet zo moeilijk om te doen hoor.

Dat ik een hekel heb aan (imho) onnodig geld uit geven, betekend niet dat ik geen extra veiligheid in mijn systeem inbouw als het gratis is.

Ik heb het al vaker geschreven. Wat jij hier schetst en doet gaat geen enkele DIY NAS bouwer die hier om advies komt vragen implementeren, de helft weet niet eens hoe.

En puur conceptueel gezien loop je ondanks je reguliere memtests nog net zo hard risico omdat geheugen spontaan stuk gaat, al je memtests ten spijt. Het is misschien beter dan helemaal niets doen, maar het is eigenlijk puur een symbolisch ritueel.

[BartNL]

player-x schreef op zaterdag 04 april 2015 @ 00:54:
[...]

Als je het AMD systeem gebruikt ben je 75 euro meer kwijt voor 8GB DDR2 ECC geheugen, plus extra verbruik, want die CPUs waren niet echt super zuinig in idle.

AM3(+) moederborden kosten minimaal 100 euro en er is veel minder keuze, FM2 ondersteund geen ECC, daarnaast is het idle verbruik hoger, en er is ook geen onboard video.

Dus zelfs als je met AMD oplossing gaat ben je ook ongeveer 100 euro extra kwijt.

offtopic:
btw, ik heb niks tegen ECC, zeer waarschijnlijk ga ik het zelf ook weer gebruiken als ik een nieuwe mobo haal, maar dat word een systeem voorbereid op 100TB+ en zal gebruikt worden door zo een 15 gebruikers, en door de kosten te verdelen over 4 gezinnen, en het meer intensief gebruik, hebben we wat meer marge in het budget.

AMD AM3+ moederbord beginnen bij €40, ddr2 ECC is inderdaad minder gangbaar, verbruik heeft de AMD een IGP voor dus verschil is genuanceerder. Ik heb een amd 705e in mijn FileServer gehad en dat is een prima zuinige oplossing.
Heb nu een intel e3 1275v2 met ECC ram in de fileserver dus echt kostenbewust ben ik niet bezig.

[ Voor 3% gewijzigd door BartNL op 04-04-2015 10:15 ]

[player-x]

Q schreef op zaterdag 04 april 2015 @ 01:26:
Sorry maar waarom ga jij voor andere mensen bepalen wat veel geld is? Of wat 'duur' is? Zou het niet eerlijker zijn om mensen dat zelf te laten bepalen?

Niet iedereen heeft een budget voor een 50+ of een 71TB server, ja imho is voor de meeste mensen 100~300 euro gewoon behoorlijk geld.

Ik beweer zelfs puur op basis van logisch denken dat ZFS tegen een risico beschermt wat kleiner is dan rot RAM geheugen.

Ooooo, dan ben ik toch echt heel benieuwd naar jouw logica, want volgens mij, en dat is gevoelsmatig, is het andersom, want ik kan nergens werkelijke feiten vinden waar ik een echte logische beslissing kan maken op basis van tests die een wetenschappelijke basis hebben, want als geheugen echt zo onbetrouwbaar is als jij doet voorkomen dan was ECC de norm geweest, en niet een dure extra beveiligingslaag.

Maar als die bliksem afleider gratis is, dan doe je opeens wel die moeite? Dat snap ik niet zo.

/me denkt dat Q niet het concept van van gratis begrijpt, tegenover zuur verdiend geld.

Overigens doe je weer met deze brakke analogie alsof het risico waar ECC geheugen tegen beschermt verwaarloosbaar is, en dat is niet waar. Dat mensen het risico wille nemen om geld te besparen, prima.

Ik geloof dat de auto analogie met de verschillende auto's redelijk goed uitlegt hoe groot ik het risico zie, als ik in een flink ongeluk terecht kom, ja dan zou ik graag de extra zij airbags hebben, betekend niet dat ik me niet prima veilig voelde in mijn oudere auto die alleen ABS en een stuur airbag had.

En puur conceptueel gezien loop je ondanks je reguliere memtests nog net zo hard risico omdat geheugen spontaan stuk gaat, al je memtests ten spijt.

Een zinnig voorbeeld, want nogmaals, het toont wederom aan dat rot geheugen een pool killed. Dat dit in dit geval bij installatie gebeurde, doet hier niets aan af.

Bij mijn weten en ervaring treden de meeste ernstige geheugen problemen op kort na installatie, daarna worden de risico's een stuk kleiner, en daar na, als er toch geheugen problemen zijn, is het meestal een probleem dat langzaam erger wordt, het is zelden poef nu is het die geheugen cel opeens 100% onbetrouwbaar.
uiteraard een geheugen cel die spontaan van waarde kan verander is bij definitie 100% onbetrouwbaar, ik heb het hier over hoe vaak het probleem optreed, en meestal is het bij mijn weten een curve die steeds erger wordt.

En als je de lange BIOS geheugen test doet, wat altijd aan te raden is op een server vang je de meeste van die problemen al op.

Zelf doe ik daar nog eens een losse test bovenop, zelfs op mijn oude offline backup server die ECC geheugen heeft.

Een burn-in test is zeker verstandig en heb ik ook gedaan met mijn systeem. Maar resultaten uit het verleden bieden geen garantie voor de toekomst. Het kan zomaar spontaan mis gaan.

Net als met de meeste andere elektronica, het gaat snel stuk of het gaat lang mee, en met een burn-in test haal je de meeste rotte appels er al uit.

Tegen de tijd dat je 's ochtends wakker wordt of terug van het werk komt is je pool al stuk toen die automatische backup liep. Zinloos wat mij betreft: put dempen als kalf verdronken is. ECC is je enige echte bescherming.

Ik geloof dat jij gelooft dat rotte dimms gelijk staat aan meteen een dode vdev, wat ik van CiPHER en andere bronnen heb begrepen is dat je eerder waarschuwingen krijgt dat er problemen met je pool zijn dan dat je pool meteen dood is.

Praten over de risico's van ECC afwimpelen als 'gek laten maken' is ongefundeerde, onjuiste rethoriek die andere mensen de keuze ontneemt om zelf een afgewogen beslissing te nemen. Jij neemt die voor hen en dat vind ik onjuist.

Als er argumenten gebruikt worden als "merkloze condooms kopen of een chinese tweedehandsparachute'', en aan de hand van dergelijke doom scenario's beslissen om ECC te nemen, ja dan hebben ze zich gek laten maken.

Tja, dit wordt een soort van cirkel redenering nu. Je projecteert je eigen visie retroactief op hun keuzes.

Nee ik geef ze imho een redelijk goede inschatting van de gevaren van het het wel en niet gebruiken van ECC.

• FAT - een jaren 60 auto zonder gordels.
• NTFS & ext4 - een jaren 70 auto met een heup gordeltje
• ZFS - een moderne auto met ABS, 3 punts gordel en airbags.
• ZFS + ECC - voegt daar nog eens zij impact airbags aan toe.

Of zeg je dat mijn hier gebruikte analogie niet klopt?

Maar laat ik het nog simpeler zeggen.

• Heb je onvervangbare data op je server staan zonder backup (niet aan te raden), gebruik ECC.
• Hecht je grote waarde aan alles dat op je server staat, maar heb je van je belangrijkste data een backup, maar je hebt het geld er voor over, neem ECC.
• Heb je voornamelijk films en van je belangrijkste data een backup, en je bereid bent om die data opnieuw te downloaden als toch onverhoopt mis zou gaan, ipv geld te besteden om een zeer beperkt risico te ondervangen, laat ECC dan maar voor wat het is

[K4F]

player-x schreef op vrijdag 03 april 2015 @ 21:48:
[...]

Een groot verschil, ECC kost veel geld, ZFS is gratis.

De performance verschillen t.o.v. andere filesystems is niet gratis.

[FireDrunk]

Ja er is verschil in benchmark performance (en soms zelfs in het voordeel van ZFS hoor ), maar in gebruikers ervaring merk ik geen enkel verschil...

[BartNL]

player-x schreef op zaterdag 04 april 2015 @ 12:04:
[...]
Of zeg je dat mijn hier gebruikte analogie niet klopt?

wanneer je ZFS vervangt door redundantie in disks misschien. Nadeel van ZFS is dan in analogie dat het op geen enkel gangbaar automerk een standaard optie is.

[FireDrunk]

Die vergelijking snap ik niet? Bedoel je daarmee dat het niet werkt onder Windows? Of dat het niet in de kernel zit?

[BartNL]

dat het niet standaard optie is onder windows en apple. Gangbare linux distro's is denk ik alleen via losse kernel module ZFS on linux te installeren.

[FireDrunk]

Windows klopt, maar er is ook al (weer) een nieuwe poort van ZFSonLinux voor OSX, maar die is nog relatief beta.

Over Kernel modules: Het zal je verbazen hoeveel gewone onderdelen van de Linux kernel als module ingeladen worden. Ubuntu bijvoorbeeld heeft alle netwerkkaart drivers als kernel modules in zijn distro zitten.

Het is ook helemaal geen probleem om kernel modules te gebruiken, en het zegt niets over de kwaliteit of 'acceptatie' van bepaalde code. Voor sommige onderdelen is het zelfs helemaal niet handig om de code in-kernel te compileren.

Kijk bijvoorbeeld naar de WiFi stack, het is daar zelfs af te raden om dit hard in de kernel te compileren.

De analogie dat ZFS niet een standaard optie is, vind ik een beetje krom. Het klinkt in mijn ogen een beetje als: Ik wil een ferrari motor in mijn panda, omdat ik wel snelheid wil, maar er niet voor wil betalen. (ZFS op Windows installeren, maar een beetje gecharcheerd).

[BartNL]

FireDrunk schreef op zaterdag 04 april 2015 @ 14:22:
De analogie dat ZFS niet een standaard optie is, vind ik een beetje krom. Het klinkt in mijn ogen een beetje als: Ik wil een ferrari motor in mijn panda, omdat ik wel snelheid wil, maar er niet voor wil betalen. (ZFS op Windows installeren, maar een beetje gecharcheerd).

ik vind het ook een kromme vergelijking om een filesystem in analogie met een auto te vergelijken.

[player-x]

BartNL schreef op zaterdag 04 april 2015 @ 17:15:
ik vind het ook een kromme vergelijking om een filesystem in analogie met een auto te vergelijken.

Je gebruikt een analogie als iets moeilijk is uit te leggen voor een leek, het is gewoon een risico vergelijking.

• Vind ik het voldoende om een airbag te hebben omdat ik mijn auto alleen maar woon/werk verkeer gebruik, (lees gebruik geen ECC).
• Of betaal ik meer voor het optie pakket met extra airbags, omdat ik +50.000km/jaar rijd, en daarom een verhoogd risico loop, of heb geld over en kan het me veroorloven, (lees gebruik wel ECC)

En ik denk dat de meeste hier de analogie best wel snapte, of heb ik dat mis?

[Q]

player-x schreef op zaterdag 04 april 2015 @ 12:04:
[...]

Niet iedereen heeft een budget voor een 50+ of een 71TB server, ja imho is voor de meeste mensen 100~300 euro gewoon behoorlijk geld.

Je mist mijn punt. Jij gaat voor andere mensen bepalen wat voor hen duur is. Stel je neutraal op. Laat mensen zelf bepalen of 150 te duur is om het risico weg te nemen, dat is niet aan jou. Je kunt gerust aangeven dat jij zelf vind dat voor thuis gebruik ECC geheugen niet nodig vind (al heel andere bewoording als 'gek') maar dat dit aan ieder zelf is om te bepalen of je het wilt toepassen of niet. Het risico is er wel.

Ooooo, dan ben ik toch echt heel benieuwd naar jouw logica, want volgens mij, en dat is gevoelsmatig, is het andersom, want ik kan nergens werkelijke feiten vinden waar ik een echte logische beslissing kan maken op basis van tests die een wetenschappelijke basis hebben, want als geheugen echt zo onbetrouwbaar is als jij doet voorkomen dan was ECC de norm geweest, en niet een dure extra beveiligingslaag.

Ik val even helemaal van mijn stoel. Lees wat je schrijft. ECC is de fucking norm In server land. Dat het niet in desktops zit is meer een anomalie, kosten gedreven, dan oog te hebben voor data veiligheid.

Google, Microsoft en Amazon hebben duidelijke statistieken vrij gegeven over hoe vaak geheugen gedonder geeft, daar is meer bewijs voor dan de noodzaak van ZFS met consumenten schijven.
Ik denk eerder dat de ZFS mensen aan zet zijn om eens een harde case te bouwen dat ZFS echt zo spannend is thuis.

/me denkt dat Q niet het concept van van gratis begrijpt, tegenover zuur verdiend geld.

Het gaat niet om het feit dat de bliksem afleider gratis is. Je afweging is dat de kans dat je door bliksem wordt getroffen heel erg klein is, zo klein dat je er geen problemen mee hebt om je er niet tegen te wapenen, terwijl de schade (impact) enorm kan zijn (kosten). Het is onzinnig om je tegen een super klein risico te beschermen, zelfs al is het gratis.

Stel ik biedt nu hier 10 forum gebruikers een gratis bliksem afleider aan, dan durf ik wel te wedden dat niemand dat aanneemt, omdat installatie een hoop gedoe is en het is het gewoon niet waard. Zelfs al is het gratis.

Let wel, ik betwist dat toepassing van ECC geheugen analoog is aan het risico van bliksem inslag, ik acht dat risico groter.

Bij mijn weten en ervaring treden de meeste ernstige geheugen problemen op kort na installatie, daarna worden de risico's een stuk kleiner, en daar na, als er toch geheugen problemen zijn, is het meestal een probleem dat langzaam erger wordt, het is zelden poef nu is het die geheugen cel opeens 100% onbetrouwbaar.
uiteraard een geheugen cel die spontaan van waarde kan verander is bij definitie 100% onbetrouwbaar, ik heb het hier over hoe vaak het probleem optreed, en meestal is het bij mijn weten een curve die steeds erger wordt.

Kijk nog eens naar de resultaten van de studies. Geheugen fouten treden spontaan op, ook later na de ingebruikname, en puur conceptueel is dat ook logisch: alles gaat spontaan stuk.

Net als met de meeste andere elektronica, het gaat snel stuk of het gaat lang mee, en met een burn-in test haal je de meeste rotte appels er al uit.

De studies tonen aan dat geheugen fouten spontaan optreden. Maar dat is ook logisch, alles kan spontaan stuk gaan.

Ik geloof dat jij gelooft dat rotte dimms gelijk staat aan meteen een dode vdev, wat ik van CiPHER en andere bronnen heb begrepen is dat je eerder waarschuwingen krijgt dat er problemen met je pool zijn dan dat je pool meteen dood is.

Dat hoeft niet direct maar de kans is er wel en het gaat wel eens mis. Het is maar net welke data structuur binnen het file system zelf getroffen wordt.

Of zeg je dat mijn hier gebruikte analogie niet klopt?

Ik vind de analogie eerder verwarring creëren dan dat het zaken verduidelijkt. Ik denk niet dat het een echte verduidelijking geeft voor DIY NAS bezoekers hierzo. Het is beter om uit te leggen wat er echt aan de hand is - zo moeilijk is dat niet - en ze zelf gewoon een keuze laten maken.

Maar laat ik het nog simpeler zeggen.

• Heb je onvervangbare data op je server staan zonder backup (niet aan te raden), gebruik ECC.
• Hecht je grote waarde aan alles dat op je server staat, maar heb je van je belangrijkste data een backup, maar je hebt het geld er voor over, neem ECC.
• Heb je voornamelijk films en van je belangrijkste data een backup, en je bereid bent om die data opnieuw te downloaden als toch onverhoopt mis zou gaan, ipv geld te besteden om een zeer beperkt risico te ondervangen, laat ECC dan maar voor wat het is

Hier heb ik niets tegen in te brengen

[ Voor 3% gewijzigd door Q op 04-04-2015 21:28 ]

[tvwes]

Goedenavond allen,

na een tijdje afwezigheid heb ik de komende tijd beperkt de mogelijkheid om weer een duit in het zakje te doen.
Er waren enkele onderwerpen de afgelopen tijd die mijn aandacht trokken en beide zijn ZFS gerelateerd.
-Performance vraagstukken aangaande overdracht tussen twee hosts.
-Expanders en backplanes.
-ECC

Waarbij ik met die laatste wil beginnen.

Zoals met zoveel zaken "wat niet weet wat niet deert". Tal van mensen hebben iets onder de leden zonder dat ze het weten. Is dat erg? Soms wel, als de ziekte te lang niet wordt gediagosticeerd kan dit leiden tot een onbehandelbare situatie met fatale gevolgen. Eerdere diagnose kan in sommige gevallen wel op tijd tot behandeling leiden met soms zelfs volledig herstel. Hier gaat de analogie al weer mank, maar niet zo mank als de diverse auto analogieën.

Wat is corrupt geheugen?
Als de cpu iets anders (corrupt) leest uit het geheugen dan wat er zou moeten staan. De oorzaak is groter dan alleen een geheugenmodule.

Waardoor kan er corrupt geheugen ontstaan?
Als de CPU iets leest uit het geheugen komt dit uit meerdere geheugen chips, gesoldeerd op een dimm, via een connector, gesoldeerd op een pcb met 8 layers, door een bus, naar een gesoldeerde cpu socket naar de cpu. Dit alles op een laag voltage bij hoge frequenties met ook nog eens een enorme hoeveelheid stoorsignalen uit de omgeving, bijv pcie bus. Hier KAN en GAAT zo af en toe iets fout. Het hoeft dus helemaal niet een kapotte chip te zijn. Het KAN ook onderweg gebeuren. De CPU krijgt 8bits + 1 extra pariteit bit terug en kan zo bepalen of de data die het terug heeft gekregen niet (onderweg) corrupt is geraakt. Behalve fouten die zijn ontstaan in de keten kan de data in de geheugen chips ook corrupt raken. Meestal wordt hier de term bitflip voor gebruikt. Vaak ontstaat dit door achtergrondstraling.
Laatste belangrijke factor is het gebruik van het geheugen. De beroemde Google paper liet zien dat naarmate het systeem het geheugen meer belaste er meer fouten op traden. De meeste thuis servers staan de hele dag niets te doen. En zullen daardoor minder fouten ervaren. Maar het blijven kansen.

De burnin test, die sommigen in deze thread als vrijwaring zien, is een moment opname. Natuurlijk is het goed om dit te doen en zelf probeer ik meestal een week hiervoor te plannen. Maar sommige opdrachtgevers vinden dat overdreven. Maar blijft een moment opname. Ik zie in de praktijk single bit errors met een frequentie van 1 keer per maand op een server tot niet bij een uptime van jaren>4. Ik weet dat en hoevaak het gebeurt omdat de systemen het rapporteren. Sommigen hier zullen zeker op hun thuis pc getroffen zijn door geheugen fouten. Maar omdat ze het niet weten is het onjuist om vervolgens te beweren dat er nooit een geheugen fout optreed. Het afdoen van geheugencorruptie als bangmakerij getuigd van grote domheid en inconsequentie als men vervolgens wel ZFS wil gebruiken. Wel accepteren dat er corruptie kan optreden op disk maar niet in DRAM. Ik verwijs nogmaals naar de Google paper die liet zien dat het een veel frequenter probleem is dan je zou vermoeden.

ECC op een x86
In de meeste x86 ECC implementaties is voorzien in detectie en correctie van een enkel corrupt bit en detectie van twee corrupte bits. ECC kan dus in meer gevallen vaststellen dat er iets fout is dan het kan herstellen.
En dat is direct de meest cruciale eigenschap, het vaststellen dat er iets fout is. De CPU zal een MCE genereren bij de detectie van een ECC fout.
Afhankelijk van het OS zal er nu een actie moeten plaats vinden. Bij een corrigeerbare fout zal deze actie meestal bestaan uit het loggen van de fout. Bij een niet corrigeerbare fout zal dit meestal een panic veroorzaken.
Waarom de panic? Gebruikers en systemen die waarde aan hun data hechten hanteren de stelregel: "Beter stoppen dan doorgaan met de wetenschap dat er geheugen corrupt is."

Nu weer terug naar een systeem zonder ECC. Met een beetje geluk was enkel een bitje corrupt geraakt van bijvoorbeeld een label van een 'Exit' knopje. Wat nu plotseling 'Exiu' heet. Misschien dat je het helemaal niet eens opmerkte en direct erna geen probleem meer want je klikte erop en weg is de applicatie en het corrupte bitje ook. Maar het geheugen was dus weldegelijk corrupt.
De meeste consumenten nemen dit voorlief. En als er iets niet lekker werkt dan zal iedereen eerst maar een keer het systeem uit en weer aanzetten zoals die aardige jongeman van de helpdesk ook altijd als eerste adviseerd. Maar ook niet iedere desktop gebruiker neemt dit voor lief. Vandaar de workstation markt. Dit zijn in feite desktop pc's alleen betrouwbaarder en dus met ECC. Waarom? Omdat deze gebruikers geen gezeur willen. Net als de beheerder van servers, die uberhaubt niet ziet dat het labeltje van de knop corrupt is geraakt. Deze groepen willen en kunnen geen gezeur gebruiken. Dus, is er iets onherstelbaar corrupt? Dan stoppen.

ECC en ZFS
ZFS gaat uit van een betrouwbaar systeem (CPU+RAM+mobo). De bedenkers waren in dienst bij een bedrijf(SUN microsystems) wat producten maakte voor de bovenkant van de zakelijke markt. De doelgroep is volkomen risico avers en zodoende was ECC altijd standaard. Hun uitgangspunt dat de cpu valide data terug krijgt uit het RAM geheugen is volkomen te begrijpen. De cpu icm met ECC geheugen kan die garantie bieden. Disk opslag kan dat niet, zonder extra hulpmiddelen. De bedenkers van ZFS erkenden dat pas in de cpu je zeker weet dat de data die je terug leest van de disk valide is. Een raid controller kan iets zekerheid bieden maar dekt een heleboel (rand)gevallen niet af. Er kan immers tussen de cpu en de disk controller ook nog van alles misgaan. De bedenkers van ZFS zagen dat de moderne CPU zoveel rekenkracht en bandbreedte heeft dat wat disk i/o processing makkelijk erbij gedaan kon worden. Dit ipv het een raid controller te laten doen. Heel simpel gesteld rekent de CPU bij ZFS voor ieder blok data een hash uit en schrijft daarna het datablok en de hash naar disk. Bij het terug lezen wordt opnieuw de hash uitgerekend van de teruggelezen data en vergeleken met de opgeslagen hash. Verschillen deze dan is er een probleem. Misschien kan het hersteld worden als er voldoende redundancy is en anders is er een ure. (De doelgroep wil niet werken met corrupte data)
Er zijn tal van redenenen die hier veel te ver gaan waarom ZFS zo gevoelig is voor RAM corruptie. Toch wil ik er twee uitlichten. Als eerste de merkle tree. Deze slaat niet alleen de hashes op van de data maar ook van de hashes zelf. Op deze manier kan je de totale integriteit valideren. Echter als bij het updaten van de ondisk merkle tree corrupte data wordt weggeschreven door dat je corrupte data uit je DRAM krijgt heb je bij ZFS direct een heel groot probleem. Het tweede zijn de metadata en dan vooral pointers. Als je verkeerde pointers gaat wegschrijven heb je ook een heel groot probleem. ZFS is veel complexer dan andere bestandsystemen. Deze complexiteit brengt veel goeds maar maakt het heel gevoelig voor geheugencoruptie en is ook veel lastiger te repareren.
ZFS vergelijken met andere filesystemen is niet gepast. Andere filesystemen hebben niet de expliciteit aanname of vereiste dat het DRAM geheugen te vertrouwen is. ZFS is niet ontworpen voor een onbetrouwbaar systeem, het is ontworpen om betrouwbare opslag te realiseren (op niet betrouwbare disks) vanaf een betrouwbaar systeem. (@player-x en anderen, als je dat onredelijk vind gebruik ZFS dan niet.) Het is niet een consumenten product het is een filesystem met unieke kenmerken die mogelijk zijn als aan een aantal voorwaarden is voldaan waaronder betrouwbaar geheugen.
Dus als iemand zijn pool verliest op een systeem zonder ecc of systeem wat niet stopt bij een niet herstelbare geheugenfout heeft het risco genomen en verloren. Niet huilen en schelden op ZFS want het is al vele malen, bij deze nogmaals, uitgelegd. Wil je geen ECC en geen risico dat je je pool niet kan importeren? Gebruik dan geen ZFS, gebruik een FS waar je wel blij van wordt met reparatie tool als chkdk of fsck. Dan kan je al je corrupte data weer lekker repareren en er mee aan de slag gaan.

Samenvatting
-Moet je ECC gebruiken? Nee, niets moet.
-Kunnen er geheugen fouten ontstaan? Ja, op ieder systeem met een cpu en dram geheugen kan er geheugen corruptie ontstaan.
-Hoeveel vaak treden deze geheugen fouten op? Of hoe groot is de kans? Voor een echte server verwijs ik nogmaals de de Google paper. Het enige wat zeker is dat de kans toeneemt naarmate het geheugen meer belast wordt. De thuis server die de hele dag staat te idlen zal er minder kans op hebben dan een server die de hele dag op 80% belasting staat.
-Moet je ECC gebruiken als je ZFS als FS wilt? Ik vind van wel. De ontwikkelaars gaan uit van betrouwbaar geheugen. Bij onbetrouwbaar geheugen kunnen er fouten ontstaan die ZFS niet in de gaten heeft en leiden tot een volkome corrupte pool. Als je toch perse ZFS icm gewoon geheugen op je cheapass bordje wilt gebruiken prima. Maar ga daarna niet lopen klagen over ZFS en dat het zo waardeloos is de er geen reparatie tool voor beschikbaar is die jij kan bedienen. Overigens zijn er diverse tools waaronder ZDB maar die zijn te moelijk voor velen. Ik verwacht niet dat degene die toch ZFS is gaan draaien op een systeem zonder ECC wel zo slim is om met deze tools nog iets van een succesvolle reparatie of partiele datarecovery uit te voeren.

Ik hoop dat ik de vragen omtrend ECC voldoende heb beantwoord en dat de ECC discussie weer een tijdje afgesloten kan worden.
Mochten er vragen of opmerkingen zijn dan hoor ik dat graag.

Bovenstaand betoog heeft betrekking op simple x86 servers. Er zijn andere systemen met betere RAS features als memory mirroring of zelfs cpu mirroring aangevuld met hotswap van memory en cpu. OA Xeon E7, Itanium, Power en Sparc bieden dit soort features.

Disclaimer: Ik heb enkele zaken zeker versimpeld. Maar niet zonder de hoofdlijn geweld aan te doen. Ik werk bijna dagelijk met en aan ZFS. Ik ken de sterke en zwakke kanten. Maar ondanks de zwakke kanten vind ik het na ruim 10 jaar nog altijd even indrukwekkend. Ik geef ruiterlijk toe dat ik fan ben en misschien een wat gekleurde mening heb. Maar bovenstaand betoog is op feiten gebaseerd. Het enige waar ik slecht tegen kan is dat de telkens weer de ECC discussie oplaait. Niks moet maar als je ZFS wilt gebruiken dan moet het wel. Doe je het niet dan heb je in mijn ogen al je rechten, op support en klagen, verspeeld.

Update 1: Ik had deze post niet in 5 minuten klaar. Mijn post lijkt misschien een herhaling van zetten in vergelijking met die van Q. Ik heb alleen getracht het wat neutraler te verwoorden zodat lezers er wat langer profijt van hebben. In hoofdlijnen ben ik het met Q eens.

[player-x]

Q schreef op zaterdag 04 april 2015 @ 21:26:
Lees wat je schrijft. ECC is de fucking norm In server land.

Correct, maar home servers staan thuis, en worden niet in dat serverland gebruikt.

Het zelfde geld voor home servers, standaard onderdelen zijn voor de meeste mensen voldoende, als je veiligheid heel belangrijk vind, of er het geld voor over hebt, is het een prima upgrade.

Ik heb zeker geen bezwaren tegen ECC, gebruik het zelf ook in mijn offline backup server, en ga het ook weer gebruiken in mijn volgende build, ik kan me alleen niet vinden in de doem scenario's voor als je geen ECC gebruikt in een homeserver.

Want imho is ZFS zonder ECC nog steeds een stap beter dan NTSF oplossingen, dus als je op een budget zit is wel of geen ECC zeker het overwegen waard.

[tvwes]

Correct, maar home servers staan thuis, en worden niet in dat serverland gebruikt.

Want imho is ZFS zonder ECC nog steeds een stap beter dan NTSF oplossingen, dus als je op een budget zit is wel of geen ECC zeker het overwegen waard.

@player-x Dit lijken mij niet de juiste afwegingen. De afweging moet zijn: Kan ik het mij veroorloven om mijn filesystem (waarvan ik weet dat ik in principe niks kan recoveren en of repareren) te verliezen (omdat ik geen ECC gebruik)?
Als je dat kan veroorloven dan moet je vooral ZFS gebruiken op een systeem zonder ECC zolang je er maar nooit over gaat klagen.
Kan je een dergelijk verlies eigenlijk niet aan, gebruik dan niet ZFS. Ieder ander filesystem (behalve BTRFS) als NTFS of EXT3 lijkt me dan een veel betere keuze. Het is volkomen geaccepteerd dat je dat gebruikt zonder ECC en er zijn diverse recovery tools en al deze filesystems gaan niet uit van een systeem met betrouwbaar geheugen.

Geld is niet de primaire afweging. Het verlies van je data is de primaire afweging. En als je het niet kan betalen dan neem je een bijbaan of kies je wat anders. Maar ga niet huilen als het misgaat omdat je geen ECC hebt gebruikt en ook niet bepalen wat duur of goedkoop is.

Niemand heeft het over doemscenario's. Een doemscenario's is een blikseminslag, een dijkdoorbraak, of de paar honder kilo illegaal vuurwerk van de buurman wat ontploft en je server in een geo stationaire baan lanceert. Dat zijn doemscenario's, geheugen fouten allebehalve. Die komen gewoon (vaak) voor. En ZFS kan daar slecht tegen. Geen doemscenario gewoon het ontwerp. Dus niks bangmakerij.

[FireDrunk]

Verander Autism voor ECC...

Ik heb er zelf op gezocht, en ik kan 3, misschien 4 mensen vinden, waar de kans aanwezig is/was dat de pool helemaal stuk ging vanwege het gemis van ECC.

*persoonlijk* vind ik dat niet een hoog genoeg getal om mij druk over te maken...
Er zijn duizenden, zo niet tien-duizenden mensen die ZFS gebruiken op non-ECC machines, waar alles dus wel blijft werken.

Uiteraard is de meting zo incorrect als maar kan, maar kort-door-de-bocht gezegd, is dat een kans van 1 op > 10.000.

Die kans is *lager* dan een bad sector / URER bij het gebruik van >2TB schijven met een 1^14 of 1^15 URER specificering in een grote RAID array / ZFS pool.

Dat is mijn redenering over waarom ECC niet verplicht is. Ik zal geen van al jullie argumenten ontkrachten, ze zijn namelijk allemaal waar, alleen is het even belangrijk om wetenschappelijk correcte meetwaardes te gebruiken ipv wat posts van mensen die hun pool kwijt geraakt zijn.

_{(Ja, er is 1 (theoretische) studie die zegt dat ECC en ZFS sterk aan te raden is., maar die gaat uit van een Enterprise omgeving waar de memory load nogal wat hoger is dan hier thuis, dus die is niet van toepassing naar mijn mening.)}

[player-x]

tvwes schreef op zondag 05 april 2015 @ 00:33:
NTFS of EXT3 lijkt me dan een veel betere keuze.

Dus wat jij zegt is dat NTSF en EXT4 veiliger zijn dan ZFS zonder ECC?

Dat is een flinke stelling, en een die ik persoonlijk voor thuisgebruikers zeker zonder hardware raid niet zomaar overneem, en zelfs met hardware raid denk ik niet dat het het betrouwbaarder is, maar ik kan het uiteraard mis hebben, maar zelfs jouw degelijke uitleg heeft mij iig nog niet overtuigt van de absolute noodzaak van ECC.

Ik geloof dat je teveel met een bedrijfsgerichte visie naar homeservers kijkt, iets dat voor jouw werk niet een slechte instelling is, maar niet geheel opgaat voor thuisservers.

Als ik mijn 57TB R6 NTSF server ga vervangen voor voor een server met BtrFS dan ga ik wel gebruik maken van ECC, daar mijn netwerk en server zwaarder dan gemiddeld word belast, en daar naast de kosten ook nog eens deel met andere, dus heb ik andere overwegingen dan iemand die een max 6 disk file servertje bouwt voor zijn films.

[Wim-Bart]

Mensen die NTSF schrijven in plaats van NTFS moet men niet te serieus nemen en laat mij twijfelen aan de kennis en kunde over bestandsystemen. Afgezien van de onzin welke over NTFS wordt geschreven in alle ZFS topics op Tweakers. Misschien een reden om eens echt in de in- en outs van NTFS te duiken.

[jacovn]

De tijd om (veel) opnieuw te moeten downloaden is me meer waard dan paar honderd euro meer voor goede hardware (met ECC geheugen) uit te geven voor een server. Maar dat is ook een persoonlijke afweging uiteraard.

[Q]

@tvwes: mooi verhaal
@Firedrunk: een beetje vals om een analogie te gebruiken met anti-vaccers. Het feit dat je mensen vindt ondersteept wat we conceptueel al a-priori weten: data corruptie in metadata van ZFS kan tot verlies leiden van de pool. Dit zijn feiten. De vraag is of je de kans wilt lopen om met die feiten geconfronteerd te worden. Het heeft niet zoveel zin om aan de hand van een paar post op internet de kans op een dode pool te bepalen.Veel meldingen zouden het sterker aantonen, maar weinig meldingen kan ook betekenen dat mensen het niet op internet melden. Je zou het echt gecontroleerd moeten meten om false-negatives uit te sluiten. Verder gaat het niet alleen om een URE, maar ook gewoon ander wonky gedrag van disks en controllers, wat vast voorkomt maar echt heel zeldzaam is.
@Wim-Bart, kom met argumenten en serveer mensen niet af om een verschrijving. Beetje zwak dit.
@Player-x: de reden waarom er thuis geen ECC wordt toegepast in desktop hardware is niet omdat het risico acceptabel is, maar puur omdat het goedkoper is, de fabrikant heeft er geen last van als het mis gaat en de consument weet niet beter. Als dat de basis is waarop je je keuze voor non-ECC baseert voor je home server: interessant.

Luister ook naar de ontwikkelaar van ZFS Matthew Ahrends:

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM.

Dat is waar, met als enige verschil dat in de praktijk het bij ZFS meteen een alles-of-niets situatie kan worden.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Letop de volgorde.....

[ Voor 44% gewijzigd door Q op 05-04-2015 10:04 ]

[player-x]

Q schreef op zondag 05 april 2015 @ 09:41:
Als dat de basis is waarop je je keuze voor non-ECC baseert voor je home server: interessant.

Het is een beetje jammer dat je dat opmaakt uit mijn argumenten, want mijn argument is gebaseerd op een risico en kosten baten afweging.

Toegeven het is niet gebaseerd op harde feiten, maar gedeeltelijk op aannames van dat de risico's niet zo hoog zijn als de ECC voorstanders zeggen, maar dat geld andersom net zo goed.

Totdat er een test is gedaan, waar iemand random bit-flips simuleert, en en een kans berekening aan per TB geschreven disk acties een kans berekening van onherstelbare fouten in files en daar naast ook de kans van verlies van de volledige vdev doet, zal deze discussie waarschijnlijk niet in het voordeel van een een van de twee stellingen beslecht wordt.

Want pas dan kan er echt een werkelijke kosten baten risico analyse gemaakt worden, is de kans op verlies van een vdev bv 1 op 1 PetaByte schrijf acties dan zou ik zeggen dat ECC absoluut noodzakelijk, is de kans 1 op 1 ZetaByte dan is voor thuis gebruik ECC niet echt nodig, zit het er ergens tussen dan moet men voor zich zelf een risico analyse maken van de kosten baten.

Ik zeg niet dat de pro ECC stelling incorrect is, want het is nog steeds een onbekend risico dat men loopt door geen ECC te nemen, maar daar tegen over staat dat ik ook geen bewijzen dat het risico niet acceptabel is, en hoewel er met het GIFje een vals argument gebruikt wordt, zit er wel degelijk ook wel wat waarheid in.

[ Voor 32% gewijzigd door player-x op 05-04-2015 11:23 ]

[Q]

player-x schreef op zondag 05 april 2015 @ 10:52:
[...]

Het is een beetje jammer dat je dat opmaakt uit mijn argumenten, want mijn argument is gebaseerd op een risico en kosten baten afweging.

De standaard in server-land is ECC. De standaard voor consumenten/thuis is non-ECC, en dat laatste was oorspronkelijk je punt. ECC is niet standaard voor thuis, en dat is 100% correct. Jij voerde dat aan als argument dat de kans op ellende door non-ECC dus niet zo groot is. Ik voer echter aan dat de reden dat we thuis non-ECC geheugen gebruiken in onze apparatuur niet een soort van eerlijk, bewust afgewogen risico is, maar puur een kosten overweging, waarbij de producenten het nadeel niet ervaren. En dat plaatst de huidige situatie waarbij we in consumenten hardware geen ECC geheugen toepassen in een andere context.

[player-x]

Q schreef op zondag 05 april 2015 @ 11:19:
waarbij de producenten het nadeel niet ervaren. En dat plaatst de huidige situatie waarbij we in consumenten hardware geen ECC geheugen toepassen in een andere context.

Maar is dat wel een argument hier in het 'DIY RAID NAS topic' waar iedereen zelf de overweging maakt om wel of niet ECC te gebruiken, ik kijk puur naar de kosten baten van ECC voor thuisgebruik, en die heeft niets te maken met afwegingen die producenten maken voor consumenten hardware.
_

Wat ik trouwens ook in mijn risico afwegingen gebruikte, maar hier nu maar ook eens hardop afvraag om de mening van andere te horen.

Heeft de gemiddelde file grote geen enorme invloed op de kans op een vdev verlies, want is er niet een groot verschil tussen een systeem waar voornamelijk films (thuis gebruik) op staan met een gemiddelde file grote van zeg 1GB, tegenover bv een database server (bedrijfsgebruik) waar bestanden van enkele KBs steeds veranderd worden.

Want er is tussen de twee volgens mij een enorm verschil in de hoeveelheid aan data, dat de interne ''risico volle'' boekhouding dat het ZFS file systeem moet doen.

[jacovn]

tvwes schreef op zaterdag 04 april 2015 @ 23:16:
-Expanders en backplanes.
-ECC

Ik kijk uit naar je verhaal over deze 2 punten.


Kreeg ik me net een ingeving !

Nog maar een share gemapped, andere SSH sessie en nog een keer een copy met MC opgestart.
En daar nog een keer 145 MB/sec copy snelheid, dus samen rond de 290 MB/sec loopt nu.

Het werkt nu met:
server 1: pool 1 (10 x 3TB raid-z2) -> server 3: pool 5 (10 x 4TB Raid-z2)
server 1: pool 2 (10 x 4TB raid-z2)-> server 3: pool 6 (10 x 4TB Raid-z2)


Dus het bron en doel systeem lijken niet zo veel moeite te hebben de data aan te leveren en op te slaan met rond 300 MB/sec. Het loopt alleen niet door 1 copy sessie met MC.

Iemand op een ander forum schreef

mc blijft bij mij op 200MB/sec en grafisch onder KDE met Dolphin filemanager kom ik tot 400-500MB/sec

Dat is een Linux systeem met ZFS en copy tussen 2 pools op zijn systeem.

Wellicht is MC de rem op alles ?

De doel machine heeft wel een iets hogere CPU belasting:
300-400% in de ZFSguru GUI. (piek van 510% gezien)

[ Voor 76% gewijzigd door jacovn op 05-04-2015 13:24 ]

[Dadona]

ECC in echte servers is toch nog wel een tandje zwaarder dan waar de meesten hier gebruik van maken: buffered versus non-buffered.

Overigens, wat die uitspraak van die ZFS dev betreft, daar vergeet hij dat ZFS zelf meer gebruik maakt van ram dan bijvoorbeeld NTFS. Mijn aanname is dat bij een intensiever gebruik van ram, de kans op fouten ook gelijk is.

Voor de rest blijf ik het hele ECC verhaal lastig vinden omdat geen van de kanten cijfers laat zien dat het niet boeit of juist wel. Uiteindelijk ben ik voor ECC gegaan omdat het voor mij de zaak in ieder geval redelijk af maakt en het prijsverschil nog te doen was voor mij. Daar speelde ook wel mee dat ik een mooie deal wist te pakken op mijn geheugen modules. Maar nu ik toch weer half naar een nieuw systeem kijk begint het feest toch weer voor af aan. En eigenlijk is het lastiger geworden. De bordjes waar ik vanuit ECC oogpunt blij van word zijn nog altijd schreeuwend duur, terwijl de non-ECC alternatieven erg goedkoop zijn geworden.
Het zou dus wel eens kunnen zijn dat ik toch weer voor een non-ECC opstelling ga.

[tvwes]

Omdat mijn post misschien te lang, te ingewikkeld of dat sommigen niet begrijpend kunnen lezen nogmaals een samenvatting:

-Geheugen fouten zijn onvoorwaardelijke kansen.
-Hoe groot deze kans is mag jezelf inschatten. De kans is niet nul. Studies van grote installaties tonen aan dat de frequentie van bijv een CE minstens 1 per dimm per jaar is. De kans is sterk gecorreleerd met de belasting van het geheugen. De (thuis)server in idle heeft een veel kleinere kans.
-ZFS is ontworpen met de aanname dat geheugen betrouwbaar is.
-ZFS maakt gebruik van veel complexere metadata structuren dan andere FS's.
-Bij corruptie van het werkgeheugen is er een kans dat een zpool verloren gaat. Hoe groot deze kans is een leuke vraag. Maar een die zeer lastig valt te beantwoorden. En niet snel beantwoord gaat worden, want zakelijke gebruikers maken gebruik van ECC. NOGMAALS het is een kans dat je de hele zpool verliest, er is ook een kans dat je alleen een file kwijt raakt, en er is ook een kans dat je het met een scrub kan oplossen.
-Ik beweer niet dat NTFS of EXT of wat dan ook beter is dan ZFS. Ik doe de suggestie dat als je geen ECC wil of kan veroorloven en je het verlies van je zpool ook niet kan veroorloven dat je dan beter een FS kan kiezen wat niet zo snel volledig verloren kan gaan en wat je kan repareren.
-De uiteindelijke beslissing over of je wel of niet ECC neemt is mag iedereen geheel zelf nemen, en ik zal niemand ergens op aanvallen. Een ieder moet zelf bepalen of hij/zij dat risico kan of wil nemen.
-Gebruikers die ZFS draaien op een systeem zonder ECC verliezen, naar mijn mening, ieder recht op support en moeten ook niet geen huilen.
-Ben ik de grote ECC fanboy? Nee helemaal niet. Alleen als de uitvinders van ZFS klip en klaar uitleggen dat ZFS uitgaat van betrouwbaar geheugen, wie ben ik om het dan beter te weten. Ik volg simpel wat in het instructie boekje staat. Sterker ik heb heel bewust honderden apparaten geplaatst zonder ECC, switches, routers en wat nog meer. Iedereen zal wel eens hebben meegemaakt dat er een switch, wifi AP plots vastliep. Waarom? Software fout? Misschien. Een geheugen fout kan ook zomaar de oorzaak zijn. Alleen kom je daar nooit achter. Dagelijks lopen er experia boxen, upc kastjes etc vast. Is dat allemaal een software probleem? Ik denk van niet. Een software probleem is als ze allemaal na een maand vastlopen bijv. Het grote verschil tussen ZFS en dit soort apparaten is dat ik bij ZFS de hele zpool kan verliezen en dat de switch na een reset weer als nieuw is.

NOGMAALS: het blijven kansen zoals alles in het leven. Wat voor de ene gebruiker een kleine kans is, is voor de andere gebruiker een hele grote kans. Ik ga niet bepalen of dat een acceptabel risico is. Niks moet. En ik ben de laatste die iemand iets voorschrijft. Mijn advies op basis van van meer dan een petabyte aan ZFS installaties is: neem ECC als je ZFS wilt gebruiken en geen gezeur wilt.


Voor de liefhebbers van de auto analogie heb ik er ter afsluiting nog een bedacht:
ZFS draaien op een server zonder ECC

is als

15W40 olie gieten in je moderne auto.

Als jij heel rustig met je auto even naar de bakker gaat en weer terug dan zal de motor het heus wel een tijd blijven doen. (zij het met de nodig slijtage) Maar als jij daarmee 60000km per jaar wilt gaan rijden zal je dat vermoedelijk niet gaan halen. Als jij afhankelijk bent van je auto en geen gezeur wilt, dan gebruik je toch simpel de olie die de fabrikant voorschrijft. Dat is met ZFS precies hetzelfde, wil je geen gezeur gebruik dan ECC zoals de ontwikkelaar adviseert.

[BartNL]

Vreemde blijft de afkeer van ZFS gebruikers tegen ECC terwijl het beide technisch goede oplossingen zijn die aanvullend op elkaar werken.
Enige reden die ik mij kan bedenken waarom ZFS gebruikers tegen ECC lijken te zijn is dat ZFS "gratis" zou moeten zijn. In die optiek is het aanraden van duurder ECC blijkbaar not done. Zeker niet wanneer je ook nog kunt beargumenteren dat het in geval van ZFS extra verstandig zou kunnen zijn.

[jacovn]

Ik heb last van bitrot op hdd's gehad die in unraid onder ReiserFS liepen. Parity disk hielp niets..
Waren maar 3 films beschadigd, maar het gevoel van dingen die weg raken terwijl je denk beschermd te zijn vond ik geen fijne ervaring.

[FireDrunk]

Ik heb absoluut geen afkeer tegen ZFS icm ECC, en kan het zelfs aanraden hoor. ECC is *ALTIJD* beter dan non-ECC...

Ik zal alleen niet snel roepen dat het *verplicht* is, omdat anders je pool per definitie ooit een keer stuk gaat...

@tvwes, heb je een bron van waar de (originele) makers van ZFS dat ECC verplicht is? Die wil ik wel graag lezen.

[ Voor 8% gewijzigd door FireDrunk op 05-04-2015 14:06 ]

[tvwes]

@friredrunk
Ik heb nooit geschreven dat het verplicht is. En ik heb ook niet geschreven dat je zpool gegarandeerd een keer stuk gaat als je geen ECC hebt.

Nogmaals de ontstaan geschiedenis: begin 2000 toen ZFS werd ontwikkeld was het een closed source product van SUN exclusief voor systemen van SUN. Veel later, ergens midden 2005, is ZFS beschikbaar gekomen als opensource via OpenSolaris. Maar ook toen was de focus van SUN niet een FS te maken voor whiteboxjes maar voor een eigen (betrouwbare met ecc) hardware. De ontwikkelaars zijn er altijd van uitgegaan dat het dram geheugen betrouwbaar was. Zij hebben dat dus nooit expliciet vereist omdat het impliciet altijd aanwezig was op SUN servers.

Ik heb het ooit van Bonwick gehoord in een praatje maar ook van anderen dat het ongeveer zo in elkaar zat. Daarnaast gaan geen van deze mensen daar een woord aan verspillen want zij gaan altijd uit van ECC. Sommigen worden ronduit kwaad als je er over begint.

Ik was deze paper even kwijt maar dit is een interessante paper die laat zien dan ZFS ondisk corruptie inclusief datapath altijd detecteerd en mits voldoende redundancy ook kan verhelpen. Corruptie in memory is een stuk minder rooskleuring. Harde cijfers voor kansen worden ook genoemd. Hier alvast uit de conclusie:

While the reliability mechanisms in ZFS are able to provide reasonable robustness against disk corruptions, memory corruptions still remain a serious problem to data integrity. Our results for memory corruptions indicate cases where bad data is returned to the user, operations silently fail, and the whole system crashes. Our probability analysis shows that one single bit flip has small but non-negligible chances to cause failures such as reading/writing corrupt data and system crashing.

Ook hier weer: er is een kans op ellende, geen garantie. Wil je die ellende niet neem dan ECC of een FS waar je wel tools voor hebt om aan recovery te doen.

[player-x]

tvwes schreef op zondag 05 april 2015 @ 13:10:
Omdat mijn post misschien te lang, te ingewikkeld of dat sommigen niet begrijpend kunnen lezen nogmaals een samenvatting:

Nee hoor je post was zeer duidelijk, en ik heb totaal geen fundamentele problemen met je argumenten.

Alleen denk ik iig dat het risico voor thuis gebruikers klein genoeg is om het risico te nemen om geen ECC te gebruiken.

En dat en nogmaals, wat ik ook in mijn risico afwegingen gebruikte, maar hier nu maar ook eens hardop afvraag om de mening van andere te horen.

Heeft de gemiddelde file grote geen enorme invloed op de kans op een vdev verlies, want is er niet een groot verschil tussen een systeem waar voornamelijk films (thuis gebruik) op staan met een gemiddelde file grote van zeg 1GB, tegenover bv een database server (bedrijfsgebruik) waar bestanden van enkele KBs steeds veranderd worden.

Want er is tussen de twee volgens mij een enorm verschil in de hoeveelheid aan data, dat de interne ''risico volle'' boekhouding dat het ZFS file systeem moet doen.

Heb ik het mis dat een ZFS video file server misschien wel meer dan een factor van een 1.000.000 minder vaak per GB aan schijfacties de kritieke metadata update dat voor een terminale verlies van een vdev kan zorgen.

Bijvoorbeeld een SAP database waar duizenden kleine veranderingen in plaats vinden, waar voor elke keer de metadata voor moet worden ge-update, tegenover een een enkele keer voor een 1.5GB grote videofile.

Hier is mijn argument voor de budget optie voor een home-server zonder ECC.

• Want je zegt ongeveer een bit-flip per dimm/jaar.
• Laten we het heel erg ruim nemen en zeggen dat er 100 plaatsvinden per jaar bij 24/7 gebruik in een 4 dimm systeem.
• Ik schat dat er 1% van de tijd schrijf acties plaatsvinden (het is veel minder, zelfs voor de meest fanatieke torrent downloaders, die geen aparte download schijf gebruiken)
• En er 0.1% van de schrijf acties metadata is (wederom het is minder)

Dan kom je uit op een kans van 1 op 100.000 dat je een vdev terminaal verlies, persoonlijk denk ik dat de kans in de praktijk eerder nog een factor 100 of zelfs veel meer groter is.

Nu het risico van onbetrouwbaar geheugen, is de zelfde kans ook niet zo groot dat een vdev er uit wordt gegooid van wegen een checksum fout ipv dat er een terminale fout gemaakt wordt in de metadata?

Vertel me als ik ergens een rekenfout heb gemaakt?

BartNL schreef op zondag 05 april 2015 @ 13:54:
Vreemde blijft de afkeer van ZFS gebruikers tegen ECC terwijl het beide technisch goede oplossingen zijn die aanvullend op elkaar werken.

Ik geloof dat er niemand hier zegt dat de keuze voor ECC een slechte keuze is, wat ik en andere wel afvragen is, heeft ECC wel echt veel zin tegenover de extra kosten die het met zich mee brengt, het dus echt een koste baten afweging, waar beide zijden goede en minder goede argumenten hebben, en door het gebrek aan harde data wordt er een discussie gevoerd over de noodzaak van de extra kosten van ECC.

Persoonlijk zou ik graag zien dat Intel ECC ondersteuning in als zijn CPUs aanzet, want dan zou ik iedereen aanraden om ECC geheugen te nemen, ook voor de desktop, en de dan 10% extra kosten voor geheugen voor lief te nemen, ipv de nu 100~300 euro extra voor ECC ondersteuning.

[tvwes]

@player-x
Je ziet het volkomen juist dat een zpool waar niet naar geschreven wordt geen risico loopt. Al zou er geheugen corruptie optreden en ZFS zou melden dat er iets corrupt is dan zou dat vermoedelijk na een scrub wel opgelost zijn (zonder dat er een repair is gedaan, het stond immers goed on disk)
Het gevaar schuilt inderdaad in het schrijven. Een druk belaste server loopt een groter risico dan een server die een keer een filmpje schrijft. Als jij na het schrijven van de film direct een scrub uitvoert zal het allemaal wel meevallen ook periodiek herstarten van je systeem zal zeker schelen.

Jouw use case is heel specifiek en alles behalve standaard. Ik denk dat je redenering en conclusie op zich goed is, namelijk het risico op totale zpool verlies van een media archief van een thuis gebruiker is zeer klein. Zo lang je maar niet schrijft maakt het allemaal weinig uit. Als je weinig schrijft loop je een klein risico. Ga meer schrijven, meer je systeem belasten dan neemt het risico toe.

Ik kan en wil niet de kosten baten afweging maken voor jouw en anderen. Voor mezelf is de meerprijs verwaarloosbaar tov de kosten van gezeur. Ook vind ik het niet fair als mensen gaan klagen over ZFS als ze geen ECC hebben en in de problemen komen.

Ik zou ook graag wat ITX bordjes met ECC zien, maar ja Intel denkt daar anders over. Ik hoop dat de oplossing gaat komen van AMD/ARM met hun Seatle/A1100. (8xsata + 2 10gb+ max 4x32GB ram)

[FireDrunk]

tvwes schreef op zondag 05 april 2015 @ 14:52:
@friredrunk
Ik heb nooit geschreven dat het verplicht is. En ik heb ook niet geschreven dat je zpool gegarandeerd een keer stuk gaat als je geen ECC hebt.

@tvwes, jij ook niet. Q wel. Die heeft er zelfs een blog over

[ Voor 67% gewijzigd door FireDrunk op 05-04-2015 17:10 ]

[tvwes]

@Firedrunk, help me even. Wat ik niet?

[K4F]

Het komt er gewoon op neer dat als je bang bent voor bitrot op filesystem of RAM niveau dat je het andere niet uit de weg kan. Of parity en checksums op een hoger niveau dan het filesystem afvangen.

[player-x]

tvwes schreef op zondag 05 april 2015 @ 15:44:
Jouw use case is heel specifiek en alles behalve standaard.

Nee ik geloof dat dat juist het doel is van de meeste bouwers hier, gewoon een plek om voornamelijk veel video data te dumpen, en eventueel als storage en/of backup van privé data van PCs en mobile apparaten.

En de reden dat ze voor ZFS gaan is omdat vooral grote disks met R5/6 NTSF onbetrouwbaarder worden

Vandaar dat ik eerder ook al zij dat jij teveel uit het oogpunt van een server admin kijkt naar thuis servers.

Ook vind ik het niet fair als mensen gaan klagen over ZFS als ze geen ECC hebben en in de problemen komen.

Ik denk dat de hele ruime meerderheid komt met vragen en problemen die helemaal niks met het gebrek aan ECC te maken hebben, mogen die mensen geen vragen meer stellen?

Ik zou ook graag wat ITX bordjes met ECC zien

Daar is best al wat keuze in hoor, vooral de Asrock Atom bordjes zijn populair daar voor, de meeste S1150 bordjes hebben maar 2x dimms van wegen ruimte gebrek, en de 2x 10 Gbit zal je met een los kaartje moeten regelen.

[Q]

FireDrunk schreef op zondag 05 april 2015 @ 16:19:
[...]

@tvwes, jij ook niet. Q wel. Die heeft er zelfs een blog over

Dat is nieuw voor mij, ik heb nog nooit beweerd dat toepassing van non-ECC geheugen per definitie tot zpool schade leidt. Dat raakt kant nog wal. Zolang je geheugen prima werkt, zal ZFS geen issues geven.

Wel mooi dat dat stomme blogje van mij #1 hit is als je zoekt op "zfs ecc". Daarin zit ook het paper waar tvwes naar verwijst.

Wat ik eigenlijk moet doen is het artikel even bijwerken en expliciet maken dat er een kans bestaat dat je de zpool kwijt raakt en hoe zich dit verhoudt tot legacy file systems zoals tvwes schetst.

[ Voor 30% gewijzigd door Q op 05-04-2015 20:56 ]

[thibautb]

Ik zit hier te twijfelen, ik heb hier nu een gewoon h97 mobo met een pentium en ga mijn pentium toch al veranderen naar een high end i3 dus eigenlijk gewoon de duurste i3. Maar zou ik nu een ecc supported mobo kopen? Die kosten wel al 180 euro goedkoopst.

En de enige reden waarom ik het echt nodig zou hebben is omdat ik een beetje twijfel over het aantal G per tb. Ik heb nu 6 gb plus 16 besteld dus 22 Gb ram voor 24tb tot nu maar daar gaan nog 10 3tb schijven bij komen en dan ga ik toch te weinig ram hebben... Ik zou mijn 6g ram ook nog kunnen veranderen in 16 dus 32 gb maar dan ga ik denk ik nog steeds niet genoeg hebben (?) Maar als ik dan ecc moederbord neem + 4 16G ram stick is dat 600 euro extra en dat vind ik toch te veel.

Wat vinden jullie ervan? Mijn data is eigenlijk vooral media die allemaal er opnieuw kan opgezet worden de belangrijke documenten staan op een andere nas die niet zoveel opslag ruimte nodig heeft... Dus ik weet dat jullie zeggen dat het kan dat met gewone memory ineens je zpool weg gaat maar dat gaat denk ik toch niet zo snel voorkomen want anders gaat iedereen er wel over bezig zijn dat ecc memory een echte must is bij zfs wat volgens mij toch niet echt het geval is....

[jacovn]

Je hebt helemaal geen 1 GB ram per TB opslag nodig voor een server die video aan 1 client oplevert volgens mij. Wordt ook tegengesproken door diverse mensen.

[thibautb]

jacovn schreef op zondag 05 april 2015 @ 21:29:
Je hebt helemaal geen 1 GB ram per TB opslag nodig voor een server die video aan 1 client oplevert volgens mij. Wordt ook tegengesproken door diverse mensen.

Dat is gewoon wat ik altijd heb gelezen. Dus ik kan met 22 g ram toekomen om zeg rond de 60tb bruto opslag te hebben met raidz

[tvwes]

@player-x Niet flauw doen, natuurlijk mag iedereen vragen stellen. Ik wil ook best mensen helpen. Zoals ik vandaag, mede voor javcon, een zfs send/recv performance trouble shooting guide heb geschreven. Maar kom niet aan met zo'n jank opmerking. Het punt was dat als mensen een corrupte pool hebben op een systeem zonder ECC ze niet moeten klagen. Om in jouw analogie te blijven als je perse een dikke auto wilt rijden moet je er het kunnen en willen betalen. Als iemand niet het geld heeft om ook nog vier fatsoenlijke banden ervoor te kopen en willens en wetens met vier niet geschikte (lees niet-ECC) banden blijft rondrijden en vervolgens verongelukt moet niet gaan verwachten dat de verzekering (lees community) iets uitkeert na een ongeluk.
Als diezelfde bestuurder met z'n niet goed uitgeruste wagen aan de community vraagt "hoe moet ik mijn interieur filter vervangen?" of "met hoeveel nm moet ik mijn kopbouten aantrekken?" Dan zal ik daar een normaal antwoord opgeven. In het geval van @javcon heb ik geen idee of hij wel of geen ECC heeft, maar ik probeer hem wel te helpen met z'n zfs send/recv vraag.

Nogmaals mijn insteek is zoveel mogelijk ellende te voorkomen, zeker bij de thuisgebruiker, die op sommige na niet al te veel backups heeft. Ik heb geen idee hoeveel gebruikers hier hun NAS voor hun pr0n collectie gebruiken vs NAS die fotootjes, email en vm's bewaren. Het zijn verschillende use cases.

De avoton/rangeley borden zijn veel te duur. En een losse 10GB nic is ook veel te duur. Net als 10 GB switches. Voor thuis. Ik hoop dat die AMD/ARM A1100 soc daar misschien wat verandering in gaat brengen. Macht der gewoonte, ik lees ongeveer direct over ASrock heen. Wat een troep hebben die in het verleden uitgebracht. Misschien is het nu allemaal wel in orde. Ik zal eens kijken naar hun aanbod. Als ik iets met een whitebox doe dan is het intel of supermicro.

Ik zal voor de rest stoppen met reacties op ECC zodat het niet in een welles nietes ontaard. Ik heb getracht de noodzaak ervan in historisch perspectief te plaatsen, wat feitelijke onderbouwing inclusief een paper die de risico's en gevolgen van memory corruption voor ZFS aantoond en alternatieven geboden.

Als iemand het geen probleem vind om na een probleem met z'n zpool enkele tb's of meer opnieuw te rippen, downloaden of copieren dan moet hij dat vooral doen. Dat is de afweging die ieder voor zich moet maken. Maar als iemand lastig te vervangen data op z'n zpool heeft staan en misschien niet een perfecte replicatie en backup strategie heeft inclusief offsite backups en dus veel paaseieren in zn NAS mandje heeft liggen zou ik die persoon niet adviseren om zfs te gebruiken zonder ECC. En anders te kiezen voor een ander FS waar je wel datarecovery mogelijkheden voor hebt. Je bent dan misschien enkele files kwijt ipv alles.

[player-x]

Q schreef op zondag 05 april 2015 @ 20:49:
Wel mooi dat dat stomme blogje van mij #1 hit is als je zoekt op "zfs ecc". Daarin zit ook het paper waar tvwes naar verwijst.

Bij mij ben je maar Nr 5, dat je je zelf als Nr1 ziet komt waarschijnlijk dat omdat Google je surf gedrag bij houd, omdat je/ze Google Analytics gebruikt op je blog.

Bij mij komt deze imho veel betere post op Nr1.

offtopic:
En ik gebruik Ghostery, Disconnect.me, WOT, μBlock en CanvasBlocker om troep buiten te houden, en privacy binnen, voornamelijk om Google buiten te houden.

thibautb schreef op zondag 05 april 2015 @ 21:36:
Dat is gewoon wat ik altijd heb gelezen. Dus ik kan met 22 g ram toekomen om zeg rond de 60tb bruto opslag te hebben met raidz

Klopt maar het is meer een vuistregel voor bedrijfsservers, niet voor thuis gebruik.

Zelf heb ik in mijn offline backup server 4GB DDR1, en tijdens het overpompen van data was de 1Gbit netwerkbelasting nagenoeg de hele tijd gewoon 100%, en meer heb je niet nodig voor een video server.

[jacovn]

Ik heb 112 GB ECC geheugen in 4 servers zitten: 32, 32, 32 en 16

[Q]

player-x schreef op zondag 05 april 2015 @ 21:46:
[...]

Bij mij ben je maar Nr 5, dat je je zelf als Nr1 ziet komt waarschijnlijk dat omdat Google je surf gedrag bij houd, omdat je/ze Google Analytics gebruikt op je blog.

Bij mij komt deze imho veel betere post op Nr1.

Haha. Net even getest via 4G op twee mobieltjes van verschillende providers en ik ben toch echt #1.
Die post waar jij naar linkt is iemand die heel goed is in het weglaten van stukjes tekst.

http://arstechnica.com/ci...5679&p=26303271#p26303271

Dit is wat Matthew Ahrens schreef:

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Dat 'Additionally' geeft aan waar hij de prioriteit legt.

thibautb schreef op zondag 05 april 2015 @ 21:36:
[...]

Dat is gewoon wat ik altijd heb gelezen.

Ik ben bang dat je de context van die vuistregel hebt gemist. Die regel is alleen voor heavy duty servers in productie omgevingen, niet voor thuis. Ik bespreek dit ook in dat artikeltje in mijn signature.

Ik draai 71TB met 16 GB RAM.

[ Voor 65% gewijzigd door Q op 05-04-2015 22:06 ]

[tvwes]

@Q Ik heb zojuist je prima artikel op je blog gelezen. Het is neutraal en je laat zien dat je bereid bent om van mening te veranderen "Why I Do Not Use ZFS as a File System for My NAS". Het is een uitgebreide engelse versie van wat ik hier schreef. Je zou misschien het historisch perspectief kunnen opnemen en tot slot in de sectie "Inform people and give them a choice" noemen dat soms een ander FS best aantrekkelijk is omdat je daar reparatie en recovery tools voor hebt. En misschien nog noemen dat een readonly zpool geen risico loopt. Een pr0n bijna readonly zpool loopt heel weinig risico. Maar het blijven persoonlijke belangen afwegingen.

Ook heb ik je recente artikel "The Sorry State of CoW File Systems" gelezen. Ik moet nog even denken over een reactie, want ik ben het niet helemaal met je eens. Wat je volkomen juist ziet is

I can imagine that in the enterprise world, this is just not that big of a deal, a bunch of drives are a rounding error on the total budget and availability and performance are more important.

Overigens is ook in de enterprise markt is ruimte kostbaar, vooral rackspace. Niemand vind het leuk om middelen te verspillen. Ik probeer klanten altijd de storage te laten op delen in profielen. VM's zijn geen database en zijn geen NAS. Door het te plannen heb ik nooit het probleem wat jij beschrijft. Ik voeg wel regelmatig extra identieke vdev's toe aan een zpool als er moet worden uitgebreid en de kosten laag gehouden moeten worden. Na voldoende (re)writes zal de zpool zich weer herbalanceren. Belangrijk is op tijd een extra vdev toe te voegen het liefst onder de 50% vol. Het meest ideale is toch een nieuwe shelf te plaatsen en te migreren naar een nieuwe zpool. Maar vaak is dat lastig ivm te korte service windows.

Ook in de thuis situatie splits ik vaak de zpool's in drieen. Een ssd only voor vm's etc, een pool met enkele mirrors voor algemeen werk en een pool voor backups en media in de vorm van een raidzx vdev bijvoorbeeld zoals hieronder
Via onboard AHCI
1 rpool mirror-0 ssd
2 rpool mirror-0 ssd
3 mpool mirror-0 2tb
4 mpool mirror-0 2tb
5 mpool mirror-1 2tb
6 mpool mirror-1 2tb
Via de onboard LSI SAS
1 apool raidz2 3tb
2 apool raidz2 3tb
3 apool raidz2 3tb
4 apool raidz2 3tb
5 apool raidz2 3tb
6 apool raidz2 3tb
7 wisselend soms leeg, soms slog, soms toegewezen extra aan de raid2
8 wisselend soms leeg, soms slog, soms toegewezen extra aan de raid2
En dat alles in 3 cages van (4x3.5" in 3x5.25 bay met 2.5" aan de zijkant) in dat in een ultra goedkope tower van sharkoon. Goedkoper kan haast niet voor thuis.

[player-x]

tvwes schreef op zondag 05 april 2015 @ 21:41:
Nogmaals mijn insteek is zoveel mogelijk ellende te voorkomen, zeker bij de thuisgebruiker, die op sommige na niet al te veel backups heeft. Ik heb geen idee hoeveel gebruikers hier hun NAS voor hun pr0n collectie gebruiken vs NAS die fotootjes, email en vm's bewaren. Het zijn verschillende use cases.

Nog steeds zeg ik dat volgens mijn berekeningen de gevaren nihil zijn, en volgens deze blog post zelfs verwaarloosbaar zijn, iig wat betreft fatale vdev fouten, daar wordt een redelijk goed onderbouwd argument gemaakt dat het ok is om geen ECC te gebruiken voor een budget ZFS server, en dat je met ZFS zonder ECC nog steeds beter af bent dan EXT4 of NTFS.

De avoton/rangeley borden zijn veel te duur. En een losse 10GB nic is ook veel te duur.

Tja dat is het eeuwige verhaal met server grade hardware, daar moet je redelijk je beurs voor trekken.

Net als 10 GB switches. Voor thuis.

Valt wel mee hoor, als je genoeg hebt aan twee of vier 10Gbit porten, dan zijn deze 2 switches een prima alternatief, als ik het goed heb gebruikt jacovn de duurdere versie thuis.

Zelf gebruik ik ThunderBolt als netwerk verbinding tussen mijn server en werk/gamePC, in mijn redelijk complexe netwerk, op de zelfde oude manier als toen Gbit switches onbetaalbaar waren.

Q schreef op zondag 05 april 2015 @ 21:55:
Haha. Net even getest via 4G op twee mobieltjes van verschillende providers en ik ben toch echt #1.

Misschien is het land gebonden, ik woon namelijk in Noorwegen.

Die post waar jij naar linkt is iemand die heel goed is in het weglaten van stukjes tekst.

Nee de vraag is of hij gelijk heeft of niet dat het gebruik van geen ECC kan lijden tot een terminale vdev, of, of dat het op zijn ergst lijd tot data corruptie van een file.

De verschillen tussen die twee uitkomsten, is een enorm verschil voor de keuze van wel of geen ECC voor een DIY NAS, daar bestandscorruptie van een of zelfs meerdere video files nagenoeg altijd op zijn ergst lijd tot glitch tijdens weergave, en niet tot totale dataverlies van je hele vdev.

Want dan zijn ze op zich iig niet slechter af dan bij ext4 of NTFS wat dat betreft.

Dit is wat Matthew Ahrens schreef:

Om eerlijk te zijn maakt het mij niet uit wat hij schrijft, want hij, tvwes en waarschijnlijk jij ook, bekijken het van uit een bedrijfsserver standpunt, er mag absoluut geen data corruptie plaats vinden, en dan ben ik het meteen met je eens ECC is een must, geen discussie!

Het punt dat ik en de andere die ECC niet zien als een absolute noodzaak, zien de corruptie van een video file, op zijn best als kleine ergernis, maar kunnen prima leven met die glitch een enkele keer dat die optreed tijdens de weergave van die bepaalde video file, en berijd zijn indien nodig heb opnieuw te downloaden.

De grote vraag is hoe groot is de kans op een terminale verlies van een vdev door non-ECC geheugen, volgens mijn zeer ruwe berekeningen is de kans dat je kritieke metadata vernield met een bit-flip, hoger dan een op een miljard, en volgens die blog post en volgens Matthew Ahrens zelf de hoofdontwikkelaar, zijn de gevaren het zelfde als voor wel ander file systeem, het schijnt zelf dat ZFS beter dan welk ander file systeem kan omgaan met bit flips, mits je een ''unsupported flag'' gebruikt.

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem. If you use UFS, EXT, NTFS, btrfs, etc without ECC RAM, you are just as much at risk as if you used ZFS without ECC RAM. Actually, ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY flag (zfs_flags=0x10). This will checksum the data while at rest in memory, and verify it before writing to disk, thus reducing the window of vulnerability from a memory error.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

Ik geloof dat deze quote meer voor dan tegen een budget non-ECC systeem zegt, want hoewel voor mij 100~300 euro extra niet een probleem is, is het wel degelijk een probleem voor sommige mensen met een beperkt budget.

tvwes schreef op zondag 05 april 2015 @ 21:41:
Ik zal voor de rest stoppen met reacties op ECC zodat het niet in een welles nietes ontaard.

Tja dat is het probleem met standpunten die voornamelijk op meningen en veronderstelling en aannames zijn gebaseerd.

Mensen hebben al genoeg problemen om de juiste beslissing te nemen, zelfs als de feiten/meningen een bepaald standpunt duidelijk ondersteunen, als dat tegen hun mening of geloof gaat, zoals bv in het vaccinatie GIFje.

Mijn conclusie van deze discussie, ECC is wenselijk maar zeker niet noodzakelijk, zeker voor privé gebruik

Dat ik deze keer best wel wat heb geleerd van de voornamelijke herhaling van stappen, en ik alleen maar stelliger ben geworden in mijn mening dat ECC niet een echte noodzaak is voor een thuisserver met het lezen van de quote van de maker zelf van ZFS.

En ga zelfs zelf een beetje twijfel over de ECC noodzaak als ik mijn BtrFS systeem ga bouwen.

[Q]

@tvwes, bedankt voor de feedback, naar aanleiding wat hier is besproken ben ik de post aan het herschrijven om het verhaal wat helderder te maken. De nieuwe versie staat online.

[Shamalamadindon]

Om de eindeloze discussie over ECC maar eens te breken....

Is de M1015 nog steeds de go to raid kaart of zijn er inmiddels goedkopere alternatieven?

[Q]

player-x schreef op zondag 05 april 2015 @ 23:41:
Nog steeds zeg ik dat volgens mijn berekeningen de gevaren nihil zijn, en volgens deze blog post zelfs verwaarloosbaar zijn, iig wat betreft fatale vdev fouten, daar wordt een redelijk goed onderbouwd argument gemaakt dat het ok is om geen ECC te gebruiken voor een budget ZFS server, en dat je met ZFS zonder ECC nog steeds beter af bent dan EXT4 of NTFS.

Zie je het commentaar onder het artikel van louwrentius? Zie je hoe ik in eerste instantie een reactie krijg, maar als ik een moeilijker voorbeeld geef, er geen reactie meer komt? En ik heb notabene het hele scrub-of-death verhaal eigenlijk weggelaten uit mijn blog, terwijl er nog best wel een case voor te maken valt.

Maar ik beargumenteer helemaal niet het scenario van de scrub-of-death. Je haalt hier allemaal dingen door elkaar. Het concept is heel simpel, als een corrupte bit metadata treft in de ZFS pool, dan kun je worst-case je pool verliezen. Het hoeft niet te gebeuren, maar het kan wel.

Nee de vraag is of hij gelijk heeft of niet dat het gebruik van geen ECC kan lijden tot een terminale vdev, of, of dat het op zijn ergst lijd tot data corruptie van een file. De verschillen tussen die twee uitkomsten, is een enorm verschil voor de keuze van wel of geen ECC voor een DIY NAS, daar bestandscorruptie van een of zelfs meerdere video files nagenoeg altijd op zijn ergst lijd tot glitch tijdens weergave, en niet tot totale dataverlies van je hele vdev. Want dan zijn ze op zich iig niet slechter af dan bij ext4 of NTFS wat dat betreft.

Zpool verlies is een reëel kans. Daar is helemaal geen discussie over.

Om eerlijk te zijn maakt het mij niet uit wat hij schrijft, want hij, tvwes en waarschijnlijk jij ook, bekijken het van uit een bedrijfsserver standpunt, er mag absoluut geen data corruptie plaats vinden, en dan ben ik het meteen met je eens ECC is een must, geen discussie!

Dit is een onjuiste voorstelling van zaken. Ik bekijk het helemaal niet vanuit een bedrijfsserver standpunt. Ik heb zelf ook aangegeven dat de risico's thuis kleiner zijn vanwege de kleinere schaal en de lagere belasting van de hardware. Maar het risico is reëel. Het risico is aantoonbaar en conceptueel ook aangetoond. Het is niet alsof de apparatuur thuis staat de risico's plots verdwijnen.

Het punt dat ik en de andere die ECC niet zien als een absolute noodzaak, zien de corruptie van een video file, op zijn best als kleine ergernis, maar kunnen prima leven met die glitch een enkele keer dat die optreed tijdens de weergave van die bepaalde video file, en berijd zijn indien nodig heb opnieuw te downloaden.

In dat geval is toepassing van non-ECC geheugen redelijk: als je met de gevolgen kunt leven.

De grote vraag is hoe groot is de kans op een terminale verlies van een vdev door non-ECC geheugen, volgens mijn zeer zeer ruwe berekeningen is de kans dat je kritieke metadata vernield met een bit-flip, hoger dan een op een miljard, en volgens die blog post en volgens Matthew Ahrens zelf de hoofdontwikkelaar, zijn de gevaren het zelfde als voor wel ander file systeem, het schijnt zelf dat ZFS beter dan wel file systeem kan omgaan met bit flips mits je ''unsupported flag'' gebruikt.

Ik snap echt niet hoe je hier allemaal bij komt wat betreft die berekeningen.

Conceptueel heeft Matthew gelijk, praktisch moeten mensen wel rekening dat ZFS geen recovery/rescue tools heeft.

ZFS can mitigate this risk to some degree if you enable the unsupported ZFS_DEBUG_MODIFY

Leuk hoor, maar geen hond met verstand in zijn neus gaat dit ooit gebruiken.

Mijn conclusie van deze discussie

Dat ik deze keer best wel wat heb geleerd van de voornamelijke herhaling van stappen, en ik alleen maar stelliger ben geworden in mijn mening dat ECC niet een echte noodzaak is voor een thuisserver met het lezen van de quote van de maker zelf van ZFS.

En ga zelfs zelf een beetje twijfel over de ECC noodzaak als ik mijn BtrFS systeem ga bouwen.

Net maakte het nog geen flikker uit wat Matthew Ahrends schrijft en nu is dat je bron om te menen dat non-ECC voor thuis toch echt wel OK is. Ik snap er niets meer van. Bovendien lijkt mij dat deze quote echt telt:

I would simply say: if you love your data, use ECC RAM.

Ik heb sterk de indruk dat je nu dingen door elkaar haalt en daar je keuzes/conclusies aan verbind.

[ Voor 6% gewijzigd door Q op 06-04-2015 01:54 ]

[player-x]

Q schreef op maandag 06 april 2015 @ 01:47:
Dit is echt totale waanzin, sorry dat ik het zeg. NIEMAND gaat hier een DIY NAS draaien met de 'unsupported flag' aan. Bovendien verkleind dat de kans alleen maar en je performance stort dan in. Je gaat toch geen unsupported debug flag aanzetten op je storage? Waar ben je dan in vredesnaam mee bezig?

Dat is zeker niet wat ik zeg, wat hij zij, en uit je eigen link naar de quote van Ahrends de ontwikkelaar:

Actually, ZFS can mitigate this risk to some degree

Het zijn zijn worden niet de mijne, of het echt een optie is in dagelijks gebruik laat ik in het midden, en ook of hij het als een echte praktijk oplossing aandraagde, of meer als een theoretische mogelijkheid.

Leuk hoor, maar geen hond met verstand in zijn neus gaat dit ooit gebruiken.

Ik zeg nergens dat het wel of niet een echt bruikbare optie is, maar als je je NAS alleen over Gbit aanspreekt is het misschien zelfs wel optie die in de praktijk geen prestatie problemen geeft, ben er wel mee eens dat geen hond het in de praktijk zal gebruiken, maar misschien is het niet eens zo een slecht optie in de praktijk.

Zpool verlies is een reëel kans. Daar is helemaal geen discussie over.

Is dat ook echt zo?, jij bent daar 100% overtuigt in die stelling, ik geloof steeds meer dat het in de praktijk het meer een theoretische kans is, iig niet groter dan bij NTFS en ext4.

Ik kom met een hele grove voorzichtige calculatie uit op een op een miljoen, en waarschijnlijk zelf hoger dan een op een miljard, met die kansen zit je toch echt meer in het gebied van theoretische kans op een pool verlies dan een reële hogere kans, dan met andere file systemen.

quote: Matthew Ahrends

There's nothing special about ZFS that requires/encourages the use of ECC RAM more so than any other filesystem.

Lees die zin nog eens goed, want hij is geschreven door de iemand die jij steeds quote voor de noodzaak van ECC, hier zegt hij pressies het tegenover gestelde wat jij zo stellig beweerd.

I would simply say: if you love your data, use ECC RAM. Additionally, use a filesystem that checksums your data, such as ZFS.

En deze quote staat echt niet in conflict met de vorige quote.

Want als ik de quote lees in zijn context "I would simply say: if you love your data, use ECC RAM.'' geld die net zo hard voor al de andere file systemen, en ook de rest van je hardware.

Maar jij leest ''I would simply say: if you love your data on your Zpool, use ECC RAM.'', en dat is zeker niet wat daar staat!

En ook is ook niet in conflict met mijn stelling dat men er beter aan doet om ZFS te gebruiken ipv juist ext4 of NTFS, zonder ECC, want:

• ZFS is net zo (on)gevoelig voor bit-flips als NTFS/ext4. (woorden van de hoofd developer)
• ZFS houd van ECC net als elk ander file systeem.
• ZFS heeft wel het voordeel van een file systeem met checksums over ext4/NTFS.
• ZFS kan file problemen voorkomen of zelfs oplossen, iets dat NTFS en ext4 niet kan.
• Een bid flip op het verkeerde moment resulteert net als bij NTFS in file corruptie, en de kans zonder ECC is hoger dan met ECC, en dat geld voor alle file systemen.

Mijn conclusie, zelfs zonder ECC ben je beter af met ZFS dan welk ander filesysteem, iig totdat BtrFS zijn raid5/6 productie klaar is.

Net maakte het nog geen flikker uit wat Matthew Ahrends schrijft en nu is dat je bron om te menen dat non-ECC voor thuis toch echt wel OK is. Ik snap er niets meer van.

Je bent af en toe behoorlijk goed in het verdraaien van mijn woorden, ik zij dat als hij puur vanuit een bedrijfsserver user case naar ECC kijkt, waar data integriteit 100% moet zijn, of daar zo dicht mogelijk bij, dat zijn mening daarover mij niet veel uit maakt, want dat is een totaal verschillende gebruiksmodel dan dat van een thuis server.

En dat wil ook niet zeggen dat ik niet naar iemand met zoveel kennis niet luister, ik zou een idioot zijn als ik zo een persoon zou negeren, en de quote over dat er geen verschil tussen ext4/NTFS en ZFS is voor de noodzaak van ECC was generaal, en dus ook relevant voor home servers.

Bovendien lijkt mij dat deze quote echt telt:

En de andere opeens niet?, of is hij irrelevant omdat hij tegen je overtuiging aan gaat dat ECC ook absoluut/behoorlijk relevant is voor thuisgebruikers.

Ik heb sterk de indruk dat je nu dingen door elkaar haalt en daar je keuzes/conclusies aan verbind.

Ik heb de zelfde gevoelens maar met een tegengestelde uitgangspunt.

Maar ik zou zeggen je blog post over ZFS + ECC is de Nr5 sorry Nr1 hit is op Google.
En zal hij misschien best willen reageren op een vragen lijstje over ECC.

Waarom stuur je hem niet mail en vraag hem wat hij denkt als expert, want uiteindelijk zijn we allemaal stuurlui die aan wal staan, jij net zo goed als ik.

Zou zeggen maak een lijst met vragen, open een topic, en vraag mensen waar je het mee eens bent en oneens of zij aanvullende vragen en/of input hebben, ik ben best berijd om over de vragen mee te denken, want ook ik zou best wel eens van de expert willen horen dat ik gelijk heb, en jij .... ongelijk hebt.

Contact Info
email: matthew dot ahrens @ delphix dot com or matt @ mahrens dot org
IRC: mahrens on FreeNode]

En post de Q&A op je blog, als hij berijd is te antwoorden, dan wordt dat vast de nieuwe informatie bron over ZFS en ECC en de nieuwe Nr1 een post op Google wat ECC + ZFS betreft.

[ Voor 42% gewijzigd door player-x op 06-04-2015 07:47 ]

[FireDrunk]

Leo1010 schreef op maandag 06 april 2015 @ 01:21:
Om de eindeloze discussie over ECC maar eens te breken....

Is de M1015 nog steeds de go to raid kaart of zijn er inmiddels goedkopere alternatieven?

Op zich als de prijs goed is, is het een prima kaart. Er is al een LSI 2308 controller die nieuwer en sneller is, maar daar zijn amper OEM varianten van.

De M1115 is een 'revisie' op de M1015 mocht je die niet goedkoop kunnen vinden, maar is nog wel gebaseerd op de 'oude' LSI2008 chipset.

Om de ECC discussie een andere kant op te sturen:

Ik zat te denken, om een scrub-of-death of iets in die geest te voorkomen, kan ik een scriptje schrijven wat automatisch een init 3 doet op het moment dat er meerdere checksum fouten gevonden worden binnen ZFS.

Dit zou er voor zorgen dat er geen IO meer gedaan wordt op je pool, en je systeem dus niet zichzelf dooddraait. (Hoe klein de kans ook mag zijn, maar daar gaat het even niet om.)

Iemand daar een mening over?

[Houston3]

ik heb een al een tijdje een nas draaien met freenas en 3 zfs pools, een voor TV een voor films en een voor overige dingen zoals muziek concerten en duikvideos die ik maak.

Nou heb ik de pools gedeeld middels CIFS met anonymous toegang. Nou gaat dit met de TV pool en de Movies pool probleemloos maar de ''Other'' pool krijg ik geen write rechten op terwijl ik exact hetzelfde heb gedaan als met de andere shares.

Iemand enig idee wat ik kan proberen om dit te fixen?

[player-x]

FireDrunk schreef op maandag 06 april 2015 @ 11:24:
Ik zat te denken, om een scrub-of-death of iets in die geest te voorkomen, kan ik een scriptje schrijven wat automatisch een init 3 doet op het moment dat er meerdere checksum fouten gevonden worden binnen ZFS

Ik heb ongeveer anderhalf uur lopen Googlen naar een praktijk geval van de scrub-of-death, en krijg het gevoel dat het meer een Unicorn is dan een echt praktisch probleem.

De scrub-of-death is meer een theoretisch probleem dat gebaseerd is volgens vele op een foute veronderstelling, dat data altijd door het zelfde blok geheugen gaat, iets dat niet gebeurd is in de praktijk.

Ik kan het mis hebben, en dat een scrub-of-death in de praktijk voor kan komen, maar het is iig niet iets dat zoveel voor komt, iig van wat ik kan zien en vinden, niet zo vaak dat er rekening mee gehouden moet worden.

[FireDrunk]

Persoonlijk kan ik het wel geloven, maar meer omdat ZFS Uberblocks zou controleren en kapot zou terugschrijven. Niet vanwege een vastzittende geheugen locatie...

De kans blijft minimaal, maar (zoals Q al vele malen aangegeven heeft) niet nul.
Als we in ieder geval dat risico ook nog weer eens minimaal maken, is dat altijd beter...

Dan kan non-ECC ZFS wel iets stuk maken, maar de kans dat je je hele pool verliest is dan eigenlijk nihil.

[MTDjassen]

Was er geen grandioos ECC vs non-ECC topic waar alle gemotiveerde geugenstrijders rustig tot in den treure welles-nietes kunnen spelen? Dit topic gaat er mijns inziens een beetje aan onderdoor.

[Gruson]

Nu ik het weer wat minder druk heb kan ik weer verder met de keuze voor componenten voor mijn ZFS NAS. Bedankt Cipher, Q en nMad voor de suggesties.

Ik heb naar de moederborden in je link gekeken Cipher, en voor mij leek de ASUS P9A-I/C2550/SAS/4L het beste aangezien daar 18 HDD's en 1 M1015 op kan wat resulteert in 26 aansluitingen. Maar: Freenas herkent de SAS controllers niet. Naast dat hij in NL niet te krijgen is op het moment.

Nu heb ik de keuzes teruggebracht tot drie moederborden: de ASRock E3C224-4L, de ASRock E3C224D4I-14S en de Supermicro X10SL7-F.

De ASRock E3C224-4L heeft genoeg PCIE sloten om 2x M1015 HBA eraan te hangen wat in totaal met de onboard SATA poorten op 24 disks uit komt. Ook het goedkoopste MB.

De ASRock E3C224D4I-14S heeft zelf al 2x mini SAS (LSI 2308 controller) op het MB en 4x sata en daar zou dus een SAS expander aan moeten kunnen. Tips voor welke goed werken icm Freenas? Slecht 1 PCIE lane. Duurste MB.

De Supermicro X10SL7-F wordt gebruikt in veel freenas builds en heeft ook de LSI 2308 controller op het MB en 8x SAS2 poorten. Hoe zit dat met verloop naar sata? Zijn daar kabels voor? Heeft 2 PCIE lanes dus er zouden ook 2x M1015 in kunnen.

Hebben jullie ervaring met deze moederborden en wat is de beste keuze voor uiteindelijk 24 disks?

Zie ik nog dingen over het hoofd en/of hebben jullie nog tips?

[jacovn]

Socket 1150 is wat beperkter dan 1155 met aantal pci-e sloten lijkt het me tot dusver. (Wel pci-e 3.0 sloten met meer bandbreedte)

X10sl7-f heeft een x8 en x4 pci-e slot.
Ik heb in de x8 een m1015 en in de x4 een 10GE nic. Dan heb je 6 mainbord, 8 sas op de 2308 chip en 8 op de M1015.

Met 2x M1015 kom je ook op 24 sas poorten en heb je de on board sata poorten voor SSD(s)
Je kunt een nieuwere LSI kaart met 16 poorten nemen en dan heb je 24x sas poorten en het pci-e x4 slot vrij. Met een nieuwe pci-e 3.0 kaart heb je dan wat meer bandbreedte. (980 MB/sec per lane tegen 500 MB/sec per lane bij pci-e 2.0) maar ze hebben geen 16i kaart met 3.0. Maar 4 GB/sec op x8 pci-e moet genoeg zijn.

[ Voor 6% gewijzigd door jacovn op 06-04-2015 18:51 ]

[player-x]

De Highpoint DC7280 DATACenter 32p HBA is misschien een (dure) optie.

[GioStyle]

Geen idee of het werkt, maar ik zou gaan voor:

ASRock E3C224D4I-14S + HP 24-Port PCI-e SAS Expander Card. Mocht je later nog een 10Gbit PCI-e kaart willen plaatsen, dan koop je een adapter voor de expander zodat het slot van de moederbord vrijkomt.

Klein, subtiel en compleet.

[Gruson]

Bedankt voor het brainstormen. Er kunnen dus 2x M1015 in de X10sl7-f for sure? Hoe ga je van die 8 SAS2 poorten op het MB naar SATA, zijn daar kabels voor?

Als er 2x gigabit op zit hoef ik er denk ik niet een 10 Gb kaart in. Snel genoeg voor thuisgebruik.

[GioStyle]

Gruson schreef op maandag 06 april 2015 @ 21:44:
Bedankt voor het brainstormen. Er kunnen dus 2x M1015 in de X10sl7-f for sure? Hoe ga je van die 8 SAS2 poorten op het MB naar SATA, zijn daar kabels voor?

Als er 2x gigabit op zit hoef ik er denk ik niet een 10 Gb kaart in. Snel genoeg voor thuisgebruik.

De 8 SAS2 poorten waar jij het over hebt zijn normale SATA poorten, afkomstig van de LSI 2308 controller, daar heb je dus geen speciale kabels nodig.

Bij mijn genoemde moederbord zitten 3 mini SAS connectoren, 2 afkomstig van de LSI 2308 controller. Daar heb je wel speciale kabels voor nodig: mini SAS naar 4x sata.

[ Voor 14% gewijzigd door GioStyle op 06-04-2015 22:10 ]

[Q]

Ik verwijs graag naar de uitgebreide post van 'tvwes' en daarmee sluit ik voor mij de discussie over ECC af.

Het enige wat Player-x beweert en CiPHER trouwens ook is dat je met non-ECC en ZFS nog steeds beter af bent dan andere file systems wat betreft data integriteit. Als je ECC-geheugen links laat liggen is de meerwaarde van dit gegeven niet meer relevant want zonder ECC-geheugen is data integriteit toch niet meer te waarborgen. Dus wie liever geen geld uit geeft aan ECC geheugen, kies eventueel gerust voor ZFS (maar weet wat je doet), maar het is volkomen redelijk om ieder ander file system te gebruiken.

[ Voor 87% gewijzigd door Q op 07-04-2015 00:39 ]

[Gruson]

GioStyle schreef op maandag 06 april 2015 @ 21:50:
[...]


De 8 SAS2 poorten waar jij het over hebt zijn normale SATA poorten, afkomstig van de LSI 2308 controller, daar heb je dus geen speciale kabels nodig.

Bij mijn genoemde moederbord zitten 3 mini SAS connectoren, 2 afkomstig van de LSI 2308 controller. Daar heb je wel speciale kabels voor nodig: mini SAS naar 4x sata.

Aha, dat was te simpel voor mij, bedankt. In de pricewatch vind ik alleen de LSI SAS 9201-16i. Zijn er ervaringen met andere (goedkopere) en beter verkrijgbare PCIE naar 4x mini sas kaarten?

[Pantagruel]

Gruson schreef op maandag 06 april 2015 @ 22:36:
[...]


Aha, dat was te simpel voor mij, bedankt. In de pricewatch vind ik alleen de LSI SAS 9201-16i. Zijn er ervaringen met andere (goedkopere) en beter verkrijgbare PCIE naar 4x mini sas kaarten?

Psst, 'use the search'

spoiler:

Iets a la de IBM M1015/M115, Dell H200 of ieder andere HBA met de LSI SAS 2008 chip

[FireDrunk]

Die hebben allemaal maar 2* mSAS
4 * mini-SAS is zeldzaam.

[Pantagruel]

FireDrunk schreef op dinsdag 07 april 2015 @ 11:41:
Die hebben allemaal maar 2* mSAS
4 * mini-SAS is zeldzaam.

klopt, overheen gelezen, my bad.

2 stuks a 2 mSAS uit de 'server pull' hoek zijn wel goedkoper dan een 16 poorts variant, maar dan moet je natuurlijk wel 2 slots beschikbaar hebben en kunnen 'missen'.

[Mr Alfabet]

thibautb schreef op donderdag 02 april 2015 @ 16:52:
Weet er iemand toevallig waar ik binnen eu/uk een Norcotek RPC-4224 kan vinden of iets dat er ongeveer op lijkt dus met 24 bays en liefst onder de 400 euro en ook atx psu. Ri-vier heeft er ook wel ongeveer zo een maar die is pas tegen begin mei terug te koop en de 3u 16 bays zijn ook niet zo handig van hun want 2u psu en natuurlijk dan maar 16 bays ipv 24 voor 320.
Bedankt!

pricewatch: Inter-Tech IPC 4U-4420

[Gruson]

Ik denk dat ik toch maar voor de 2x 1015 ga. Aangezien ik dan toch eerst 1 plaats en dan later nog 1, of gelijk een upgrade naar een 16x variant.

Bedankt voor het meedenken, het wordt een X10sl7-f, ik ga hem deze week bestellen.

[Mr Alfabet]

Ik heb een vraagje: Ik heb nu een Ubuntu ZFS NAS met samba draaien, maar als ik een 1080p mkv film af probeer te spelen over het netwerk met een Windows PC en VLC media player speelt hij wel, maar als ik de film vooruit probeer te skippen blijft hij hangen. Moet ik per se iets als Plex of XBMC installeren om films te kijken over het netwerk?

[MTDjassen]

Als je denkt dat het hangen komt omdat je netwerk/SMB het niet trekt dan kun je Plex installeren, die transcodeert serverside waardoor je netwerk load als het goed is afneemt.

Anderzijds kun je XBMC installeren op je media player zodat je makkelijk een NFS share kunt aanspreken vanaf je Ubuntu nas. Die zijn over het algemeen stabieler dan SMB shares.

Overigens is het overall voor user interface wel chill om Plex/XBMC te draaien ipv VLC via een samba share, maar dat is persoonlijke voorkeur uiteraard .

[ Voor 18% gewijzigd door MTDjassen op 07-04-2015 16:38 ]

[MTDjassen]

-huh dubbel geplaatst-

[ Voor 113% gewijzigd door MTDjassen op 07-04-2015 16:37 ]

[BartNL]

@Mr Alfabet
mkv afspelen werkt bij mij beter met MPC-HC dan met VLC dus zou je ook nog kunnen proberen.

[Mr Alfabet]

MTDjassen schreef op dinsdag 07 april 2015 @ 16:36:
Als je denkt dat het hangen komt omdat je netwerk/SMB het niet trekt dan kun je Plex installeren, die transcodeert serverside waardoor je netwerk load als het goed is afneemt.

Gewoon bestanden overzetten van en naar de share gaat met 60 MB/s, dus dat zit wel snor.

Anderzijds kun je XBMC installeren op je media player zodat je makkelijk een NFS share kunt aanspreken vanaf je Ubuntu nas. Die zijn over het algemeen stabieler dan SMB shares.

Kan XBMC op een Windows pc NFS shares aanspreken? Dat is wel erg chill.

Overigens is het overall voor user interface wel chill om Plex/XBMC te draaien ipv VLC via een samba share, maar dat is persoonlijke voorkeur uiteraard .

Wellicht, ik zal het eens een kans geven.

BartNL schreef op dinsdag 07 april 2015 @ 22:25:
@Mr Alfabet
mkv afspelen werkt bij mij beter met MPC-HC dan met VLC dus zou je ook nog kunnen proberen.

In het algemeen, of beter via de NAS?

[ Voor 12% gewijzigd door Mr Alfabet op 08-04-2015 00:05 ]

[Michelli]

Ik heb ook besloten om binnenkort een server/NAS te gaan bouwen, hoogstwaarschijnlijk met FreeNAS erop. Gezien de router thuis in de woonkamer staat, heb ik besloten om een compacter systeem te bouwen.

#	Product	Prijs	Subtotaal
1	Supermicro A1SAi-2550F (Retail Pack)	€ 301,50	€ 301,50
8	WD Green WD30EZRX	€ 101,95	€ 815,60
1	Silverstone DS380	€ 155,41	€ 155,41
2	Kingston ValueRAM M1G64KL110	€ 65,38	€ 130,76
1	IBM ServeRAID M1015 SAS/SATA Controller for System x	€ 128,36	€ 128,36
1	Silverstone SX500-LG	€ 79,59	€ 79,59
Bekijk collectie Importeer producten		Totaal	€ 1.611,22

Het systeem zal voornamelijk dienen als file- en downloadserver. Eventueel dat ik ook Plex ga uitproberen en het dus 1 à 2 streams zal transcoderen.

Iemand nog tips? Alvast bedankt iig

[Shamalamadindon]

Waarom dat Supermicro bord? Met de ASRock C2550D4I heb je de M1015 niet nodig.

pricewatch: ASRock C2550D4I

[Michelli]

Leo1010 schreef op woensdag 08 april 2015 @ 00:53:
Waarom dat Supermicro bord? Met de ASRock C2550D4I heb je de M1015 niet nodig.

pricewatch: ASRock C2550D4I

Dat moederbord heb ik over het hoofd gezien

Die is inderdaad ook erg interessant. USB 3.0 zal ik waarschijnlijk toch niet snel gaan gebruiken, dus zal ik niet missen.

Waarschijnlijk zal het dan dus zoiets worden:

#	Product	Prijs	Subtotaal
1	ASRock C2550D4I	€ 314,50	€ 314,50
8	WD Green WD30EZRX	€ 101,95	€ 815,60
1	Silverstone DS380	€ 155,41	€ 155,41
1	Crucial CT2KIT102472BA160B	€ 161,-	€ 161,-
1	Silverstone SX500-LG	€ 79,59	€ 79,59
Bekijk collectie Importeer producten		Totaal	€ 1.526,10

Bieden de WD Reds trouwens nog echte voordelen tov de Greens, behalve de extra garantie?

[jacovn]

Maar die asrock heeft 12 poorten, dan kom je met 1 M1015 erbij maar tot 20. 1 PCI-E slot dus het houdt op met 20 poorten.
Dan ben je met een x10sl7-f toch beter uit wellicht.

[Dennis]

jacovn schreef op woensdag 08 april 2015 @ 06:25:
Maar die asrock heeft 12 poorten, dan kom je met 1 M1015 erbij maar tot 20. 1 PCI-E slot dus het houdt op met 20 poorten.
Dan ben je met een x10sl7-f toch beter uit wellicht.

Maar dat is geen mini-ITX en past dus niet in je DS380.

[MTDjassen]

Mr Alfabet schreef op woensdag 08 april 2015 @ 00:04:
Kan XBMC op een Windows pc NFS shares aanspreken? Dat is wel erg chill.

Yes: http://kodi.wiki/view/NFS

[jacovn]

Dennis schreef op woensdag 08 april 2015 @ 07:00:
[...]

Maar dat is geen mini-ITX en past dus niet in je DS380.

Goede opmerking, ik haal posts door elkaar. Met 8 hotswap bays heb je meer dan genoeg poorten inderdaad..

[Michelli]

jacovn schreef op woensdag 08 april 2015 @ 08:19:
[...]

Goede opmerking, ik haal posts door elkaar. Met 8 hotswap bays heb je meer dan genoeg poorten inderdaad..

Zelfs al zou ik later 4 2,5 inch drives toevoegen, is dat zelfs nog mogelijk

[player-x]

Michelli schreef op woensdag 08 april 2015 @ 17:02:
Zelfs al zou ik later 4 2,5 inch drives toevoegen, is dat zelfs nog mogelijk

Persoonlijk ben ik meer een grote fan van het gebruik van 2.5'' HDDs als OS en tijdelijke download schijf.

Ik kijk 95% van de tijd mijn gedownloade video's eerst vanaf mijn download schijf, op die manier bespaar ik stroom en de verleng ik de levensduur van mijn raid array, en voorkom ik veel disk fragmentatie.

En eens per maand of zo, verplaats ik wat ik heb gezien en wil bewaren naar de raid array.

Bijvoorbeeld de Toshiba MQ Series, 2TB de goedkoopste 2TB 2.5'', (maar er zijn ook genoeg kleinere goedkopere alternatieven), verbruikt 0.7W idle en 1.7W read/write, daarnaast is volgens sommige bronnen de betrouwbaarheid van 2.5'' HDDs ook hoger dan die van desktop model, omdat ze gebouwd zijn voor laptops die een hogere schok bestendigheid nodig hebben, een mening waar ik ook in mee ga.

• Voltage - 5.0 V (+/- 5%)
• Spin up (start) Power - 4.5 watts (Max.)
• Seek Power - 2.20 watts (Typ.)
• Read/Write Power - 1.7 watts (Typ.)
• Low Power Idle - 0.70 watts (Typ.)
• Standby Power - 0.18 watts (Typ.)
• Sleep Power - 0.15 watts (Typ.)

En de tijd dat 2.5'' HDDs langzaam waren is ook al lang voorbij, met zijn 175MB/s.

In mijn ervaring zijn ze de ideale OS/tijdelijke download schijven, en gebruik ze al jaren speciaal daar voor in mijn server builds.

Maar daarnaast kan je natuurlijk ook een (oude) SSD voor het OS gebruiken.

Zelf heb ik deze optelling.

C:\ 128GB SSD (systeem)
D:\ 1TB 2.5'' (temp download)
E:\ 2TB 2.5'' (downloads)
F:\ 4TB Green (*) (muziek collectie)
G:\ 55TB array
(*) Hier zou je ook een 2.5'' schijf voor kunnen gebruiken - backup op naar G:\ 1x per week

Waarom een losse muziek schijf, omdat zowel ik als mijn vrouw als we thuis zijn vrijwel altijd muziek op de achtergrond aan heb, en op deze manier wordt de array minder belast, ben je voornamelijk een Spotify only muziek lief hebber, of luister je gewoon weinig naar muziek, dan is die natuurlijk gewoon overbodig.