Het grote DIY RAID NAS topic deel 3

[Verwijderd]

Mag ik voorstellen om de ECC discussie even te laten bevriezen totdat ik een mooi topic heb aangemaakt, waar we ééns en voor altijd de discussie goed kunnen voeren? Dus alle argumenten uitgebreid verkennen en tot een consensus komen over de zaken waar we niet over van mening verschillen, evenals een conclusie over de zaken waar we wel over van mening verschillen.

Dat lijkt mij veel meer nut hebben dan elke week in dit topic het ECC evangelie te bediscussiëren, want onderhand is het een kerkdienst geworden met trouwe aanhang en seculiere critici die elkaar te lijf gaan met allerlei argumenten. Voor buitenstaanders is de discussie ook nauwelijks te volgen en waar rook is, is vuur. Dat eist zijn slachtoffers, zoals de recente gebeurtenissen in dit topic maar eens bewijst.

Kortom, tijd voor een andere aanpak.

[Q]

player-x schreef op zondag 23 november 2014 @ 00:38:
Ik zou dus dus zegen, houd daar alsjeblieft mee op, en zeg gewoon dat ECC wel aan te raden is voor thuis gebruikers, maar zeker geen absolute noodzaak, want voor de meeste zien hun thuis servers niet als een 'Mission Critical Systems', en de reverentie materiaal waar jij je persoonlijke en zeer sterke mening op baseert doen dat wel.

Waar ik over val denk ik in de hele discussie is dat 'jullie' roepen dat ECC niet noodzakelijk is. Maar als je om data integriteit geeft dan is dat wel noodzakelijk. Dan is alleen ZFS niet voldoende. En dat zeggen jullie nooit in jullie advies.

De argumenten die worden toegepast om de noodzaak van ECC geheugen te bagataliseren kun je 1-op-1 toepassen om de noodzaak van ZFS te bagataliseren.

Ik heb er geen enkel probleem mee als mensen - op basis van complete informatie - er voor kiezen om ZFS te draaien zonder ECC geheugen. Dat ze zelf hun eigen risico afweging maken. Maar dan moet die informatie wel geboden worden.

@CiPHER, ik vind het erg onsympathiek van je hoe je stelselmatig de discussie kleurt met termen als de ECC-kerk / religie. En Maffia, etc. etc. Ik wil je vragen om dat soort zaken te laten, het is oneerlijk en het kan 1-op-1 omgedraaid worden. Dus kunnen we de ad-hominems achterwegen laten?

[ Voor 13% gewijzigd door Q op 23-11-2014 10:06 ]

[Ultra]

* Ultra schaart zich achter Q. Keurig genuanceerd: ECC is beter dan geen ECC en ZFS is beter dan de meeste andere file systems.

Verwijderd schreef op zondag 23 november 2014 @ 00:46:
Dat lijkt mij veel meer nut hebben dan elke week in dit topic het ECC evangelie het ECC-is-onzin-evangelie te bediscussiëren

FTFY.

[Verwijderd]

@Ultra: dat is een open deur; niemand is het daarmee oneens. Het gaat nu juist om de nuancering en relativering van de argumenten. Hoeveel beter is ECC en hoe verhoudt zich dat tot de wenselijkheid cq. noodzakelijkheid ervan voor een ZFS NAS. Pas als je dat helder krijgt uitgelegd aan het grote publiek kun je ongelukjes zoals recent voorkomen.

@beide: het 'evangelie' kun je op beide kampen toepassen inderdaad; het is niet enkel toepasbaar op diegenen die stellen dat ECC noodzakelijk is voor een ZFS server. Het is enkel een aanduiding dat de discussie best 'fel' wordt gevoerd en er van toenadering nauwelijks sprake lijkt. Dat blijkt ook wel uit de reacties waarbij de discussie behoorlijk persoonlijk wordt genomen en mensen zich snel voelen aangevallen. Mijn advies is: doe dat niet, dat is het niet waard. Het is maar een tech-discussie op het internet.

[ Voor 26% gewijzigd door Verwijderd op 23-11-2014 11:51 ]

[Afwezig]

Het valt mij op dat we ongeveer even veel posts kwijt zijn om te bediscussiëren over hoe we met elkaar een discussie gaan voeren als over de techniek waar we vervolgens gaan discussiëren. En ik doe daar nu ook aan mee. Mijn vraag is; hebben we wel al die spelregels wel nodig over hoe we de discussie op betrekkingsniveau met elkaar voeren? Naar mijn idee niet. Ik denk dat we prima in staat zijn met z'n allen een discussie te voeren over de inhoud en daar lijkt mij dit topic heel relevant voor. Als je het niet eens bent met de woordkeus van een ander of dat je het idee hebt dat je 'aangevallen' wordt om je standpunt heb je altijd nog de keus om daar niet op te reageren. Niemand heeft wat aan onderling gekibbel. Wat mij betreft; game on, op de inhoud.

Wat betreft die inhoud:

Ik heb er geen enkel probleem mee als mensen - op basis van complete informatie - er voor kiezen om ZFS te draaien zonder ECC geheugen. Dat ze zelf hun eigen risico afweging maken.

Dit.

[Verwijderd]

Maar of jij daar persoonlijk een 'probleem' mee hebt is ook niet erg nuttig voor de ander. Welke informatie is nu nuttig voor mensen die een NAS willen bouwen en moeten weten of ze nou persé voor ECC moeten kiezen of dat non-ECC voor hun situatie ook verantwoord is? Dat is nuttige informatie. Een goed en helder overzicht hierover lijkt me wenselijk, ook om de alsmaar terugkerende en dus versnipperde discussie in dit topic tegen te gaan. Want ik heb zelf ook geen zin mijn eigen argumenten elke week te herhalen. En ik kan me voorstellen dat dit ook voor andere spelers in het debat geldt.

Ik had een mooi topic geschreven met bepaalde stellingen in de topicstart, waar een ieder deze kon kopiëren en hierop kon reageren. Om zo tot een gestandaardiseerde discussie te komen waarbij de meningen goed kunnen worden vergeleken en open deuren als 'ECC is beter' kunnen worden vermeden. Helaas is dat topic verloren gegaan door een onhandigheid van mijzelf; sindsdien heb ik nog niet de moeite genomen het opnieuw te schrijven. Maar zoiets lijkt me wel beter dan de versnipperde discussie in dit topic.

Uiteindelijk gaat het om de nieuwkomers die een afweging moeten maken voor wat betreft de hardwarekeuze van hun NAS. Als dat te ondoorgrondelijk is en er allerlei onheilspellende berichten over non-ECC naar buiten komen zonder dit in perspectief te plaatsen, kun je ongelukjes krijgen zoals recent is gebeurd. Vandaar dus mijn voorstel dit in een apart topic te behandelen. Dan kunnen ook de extreme meningen (ECC is noodzakelijk - ECC is onzin) worden beconcurreerd door meer genuanceerde en breed gedragen meningen.

[Dadona]

CiPHER, je mist blijkbaar het punt. Door er zelf een kwalificatie van een evangelie aan te hangen kleur je de discussie. Je bestempelt een kant (los van welke) tot een evangelie.

Ik hoor verwijzingen naar risico afweging. Of de kans. Of juist met NTFS/ZFS/...... Dit terwijl ik de cijfermatige onderbouwing compleet mis. Ik heb nu een beperkt aantal studies gezien rondom ECC. Maar ik mist het duidelijke overzicht, dit is de kans, in dit scenario, dat je verkeerde data gaat wegschrijven.
Als die data er is, dan kun je zelf bepalen wat voor jou de impact zou zijn, combineer dat met de mitigerende kosten en risk apetite en iedereen kan voor zichzelf tot een geheel valide afweging kunnen komen. Maar dat eerste bouwsteentje, de kans op impact mis ik.

Nu zijn er scenarios waarin je voorbij kunt gaan aan de hele afweging. En één daarvan gaat voor mij op. Ik wou ZFS, ging er vanuit dat ZFS meer gebruik maakt van geheugen en daarom eerder tegen de kans van geheugen fouten aan kan lopen. En daar ben ik min of meer gestopt met mijn kwalitatieve analyse. Ik heb gekeken wat voor data er op het systeem zou komen, wat de meerprijs was voor een ECC opstelling en om die reden meteen door gestapt naar ECC. En zeer recent is zowel mijn werkstation als mijn nas voorzien van ECC.
Maar nog altijd weet ik niet welke kans ik nu heb weggenomen op welke impact. Het is meer dat ik dat risico, wat het ook moge zijn, voor zover redelijk heb uitgesloten.

[Verwijderd]

Een wetenschappelijk verantwoorde studie naar de gevaren van tijdelijke en permanente datacorruptie is lastig; daar hebben wij de middelen niet voor. Niemand in de wereld, voor zover ik weet, heeft een dergelijke studie uitgevoerd. De studies die er zijn, zijn beperkt in scope. Analoog aan het falen van hardeschijven of SSDs. Perfect als je zou weten de M500 heeft 0,8% kans om te falen per jaar en de Samsung 840 heeft 1,2% kans; maar dergelijke cijfers hebben we simpelweg niet.

Toch kun je denk ik met een beperkte scope al heel veel ondersteuning krijgen voor de afweging om wel of geen ECC build te bouwen. Bijvoorbeeld: hoe hoog de kans op bitflips bij non-ECC RAM is, is enigszins irrelevant voor de vraag wat er zou gebeuren als je RAM een bitflip heeft. Kortom, de cijfers over frequentie beïnvloeden niet de gevolgen van bitflips in RAM.

Nu heb ik in het verleden tests gedaan met defect RAM die zeer veel bitflips genereerde. Het lijkt mij dat dergelijk redelijk simpel uit te voeren testjes, erg nuttig kunnen zijn voor de discussie. Een goede studie naar de kans op bitflips is zeer lastig uit te voeren met beperkte middelen, maar zulk soort testjes vallen binnen de scope van wat mogelijk is voor ons stervelingen.

Dan geldt het interpreteren van de resultaten. Voorbeeld: in mijn tests werd er daadwerkelijk behoorlijk wat corrupte data naar de pool geschreven. Maar alle corruptie werd na een scrub evengoed weer hersteld. Tijdelijke en permanente datacorruptie zijn dus zaken die je gescheiden moet houden. De vraag is hoe erg het is indien applicaties corrupte gegevens aangeleverd krijgen (End-to-End data protection) en hoe erg het is om permanent gegevens te verliezen. Dat laatste lijkt mij voor een thuis NAS veel belangrijker dan het eerste. Echter, de studies die worden aangehaald, focussen zich enkel op het eerste probleem.

Je noemt dat ZFS veel geheugen gebruikt; maar dat is eigenlijk niet waar. Andere filesystems (eigenlijk: virtual filesystems; VFS) zoals NTFS/Ext4 gebruiken meer RAM omdat alle inactieve RAM daar voor filecache wordt gebruikt. De exposure is dus minder groot. Maar ZFS gebruikt de RAM ook voor andere doeleinden dan enkel filecache; ook voor de berekening van checksums en dat is denk ik het belangrijkste risico; dat een checksum verkeerd wordt aangemaakt.

Met een aantal testjes die jullie hopelijk ook willen uitvoeren, kunnen we ook over wat gegevens en praktijkervaring beschikken om de discussie iets meer body te geven, dan enkel theorycrafting.

[Dadona]

De kans wil ik zeker niet uit het raam gooien. Kun je dat niet vaststellen of goed schatten dan ben je al klaar. Geregeld komen er vliegtuigen over het huis, de impact kan zijn dat het totale huis zal worden weggevaagd. Ik wil echt niet alleen naar de impact kijken, sterker nog, daar kijk ik later naar.
Daarbij, de kans kun je natuurlijk wel detecteren. Dat is het punt juist van ECC. Die momenten moet je vastleggen.

[Q]

Verwijderd schreef op zondag 23 november 2014 @ 12:30:
Maar of jij daar persoonlijk een 'probleem' mee hebt is ook niet erg nuttig voor de ander.

Ik geef aan dat ik het oneerlijk vindt hoe makkelijk jij en anderen het risico dat ECC RAM afdekt wegwuift en bagatelliseert en letterlijk tegen mensen zegt dat het voor hen in hun situatie prima is om geen ECC geheugen te gebruiken, dat dit een acceptabel risico is. Laat die mensen dat voor zichzelf uitmaken?

Welke informatie is nu nuttig voor mensen die een NAS willen bouwen en moeten weten of ze nou persé voor ECC moeten kiezen of dat non-ECC voor hun situatie ook verantwoord is? Dat is nuttige informatie.

Of een bepaalt risico voor hun situatie verantwoord is, moeten die mensen zelf bepalen en dat kunnen jij en ik niet voor hen bepalen. Je kunt dus niet stellen dat: in situatie x, y of z is toepassing van non-ECC geheugen verantwoord. Maar dat doe jij en anderen wel.

Een goed en helder overzicht hierover lijkt me wenselijk, ook om de alsmaar terugkerende en dus versnipperde discussie in dit topic tegen te gaan. Want ik heb zelf ook geen zin mijn eigen argumenten elke week te herhalen. En ik kan me voorstellen dat dit ook voor andere spelers in het debat geldt.

Mee eens.

Uiteindelijk gaat het om de nieuwkomers die een afweging moeten maken voor wat betreft de hardwarekeuze van hun NAS. Als dat te ondoorgrondelijk is en er allerlei onheilspellende berichten over non-ECC naar buiten komen zonder dit in perspectief te plaatsen, kun je ongelukjes krijgen zoals recent is gebeurd. Vandaar dus mijn voorstel dit in een apart topic te behandelen. Dan kunnen ook de extreme meningen (ECC is noodzakelijk - ECC is onzin) worden beconcurreerd door meer genuanceerde en breed gedragen meningen.

Zie hoe ik subtiel weer de schuld in de schoenen geschoven krijg dat een gebruiker niet voor ECC en ZFS kiest. Dat ik onheilspellende berichten over non-ECC verspreid zonder dit in perspectief te plaatsen, wat ik wel degelijk doe. Keer op keer kan jij CiPHER, het niet laten om zo gekleurd te schrijven.

- Ondoorgrondelijk
- Onheilspelelnde berichten
- extreme meningen
- meer genuanceerd / breed gedragen meningen

Allemaal subtiele schrijfstijl trucjes om continue je visie er door te laten sijpelen en de anderen weg te zetten als onheil verspreiders, extreem en ongenuanceerd, etc. Dat hoort niet thuis in een discussie.

Verwijderd schreef op zondag 23 november 2014 @ 13:35:
Met een aantal testjes die jullie hopelijk ook willen uitvoeren, kunnen we ook over wat gegevens en praktijkervaring beschikken om de discussie iets meer body te geven, dan enkel theorycrafting.

Ik weet niet wat je precies voor ogen hebt qua tests, maar op de schaal van een aantal forumleden denk ik niet dat dit enig nut heeft.

Ik ben misschien een beetje een buzzkill maar ook wat betreft de tests die jij hebt gedaan met wat rotte reepjes geheugen zijn wat mij betreft niet representatief, daar heb ik al eens eerder iets van gezegd maar een reactie heb ik naar mijn weten niet gekregen.

[ Voor 12% gewijzigd door Q op 23-11-2014 13:56 ]

[Verwijderd]

Q, als je een probleem hebt met mijn schrijfstijl of je persoonlijk voelt aangevallen, waarom stuur je me dan geen DM? Kunnen we erover praten.

Ik val je helemaal niet aan althans dat is zeker niet mijn bedoeling. Ik geef inderdaad wel af op ongenuanceerde meningen ('evangelie') omdat het los van de realiteit of nuance lijkt geslagen. Maar dat geldt voor beide kampen. Eerlijk toegegeven, ik zie dit vooral in het kamp dat ECC sterk propageert en min of meer stelt dat ZFS geen zin heeft als je geen ECC build hebt. Dan doel ik ook vooral op bepaalde sites en bijvoorbeeld het FreeNAS forum. De dingen die daar te lezen zijn; dat noem ik evangelie. Sommige dingen die hier worden gezegd eveneens. Maar er zijn prima respectabele en genuanceerde meningen die stellen dat ECC zéér wenselijk is voor een ZFS build voor thuisgebruikers. Dat noem ik geen evangelie.

Je hebt het over gekleurd; maar mag ik zelf geen mening hebben? Je weet dat ik vooral reageer op dit forum als gebruiker, niet als moderator. Zie me dus als je gelijke; jij hebt een mening en ik ook. We mogen toch allebei onze argumenten op tafel leggen? Daarnaast probeer ik ook aan te geven dat het voeren van een ongenuanceerde discussie met extreme stellingen weinig nuttig is voor beginners die hun ZFS NAS willen bouwen. Als die allerlei onheilspellende berichten blijven lezen zonder gefundeerde onderbouwing, kan dit onbedoelde effecten hebben. Ik mag aannemen dat jij het afketsen van een ZFS build omdat iemand 'horrorverhalen' heeft gelezen over non-ECC, toch ook niet is wat jij wilt?!

[Q]

Doe je het weer. Je kunt het niet laten. Mijn voorstel laat termen als:

- ongenuanceerd
- evangelie
- los van de realiteit
- extreme stellingen

achterwege in de discussie. Het voegt inhoudelijk helemaal niets toe.

[ Voor 7% gewijzigd door Q op 23-11-2014 14:03 ]

[Verwijderd]

Ik ga over mijn eigen woorden, en ik vind dat ik het goed heb verwoord. Als je daar een probleem mee hebt kun je contact met mij opnemen, of desnoods dit bij een (ander) crewlid aankaarten.

Mag ik verzoeken het weer over de inhoud te hebben?

[Q]

Waarom kunnen we daar niet in alle openheid over spreken? Ik heb geen reden om een ander crewlid hierover aan te spreken, het gaat mij niet om jou, je bent niet de enige die zo schrijft.

Het gaat om het principe hoe je een discussie voert. Snap je waarom ik van mening ben waarom die woorden niet in een discussie thuis horen?

[Verwijderd]

Persoonlijke vetes dienen niet op het forum uitgevochten te worden. Als jij een probleem hebt met mijn schrijfstijl of je persoonlijk voelt aangevallen, kun je dat persoonlijk met mij bediscussiëren.

[Q]

CiPHER, dit is geen persoonlijke vete voor mij. Je bent niet de enige die zo schrijft. De manier waarop een discussie wordt gevoerd is voor iedereen relevant.

[IceTeaGX]

Verwijderd schreef op zondag 23 november 2014 @ 00:46:
Mag ik voorstellen om de ECC discussie even te laten bevriezen totdat ik een mooi topic heb aangemaakt, waar we ééns en voor altijd de discussie goed kunnen voeren? Dus alle argumenten uitgebreid verkennen en tot een consensus komen over de zaken waar we niet over van mening verschillen, evenals een conclusie over de zaken waar we wel over van mening verschillen.

Dat lijkt mij veel meer nut hebben dan elke week in dit topic het ECC evangelie te bediscussiëren, want onderhand is het een kerkdienst geworden met trouwe aanhang en seculiere critici die elkaar te lijf gaan met allerlei argumenten. Voor buitenstaanders is de discussie ook nauwelijks te volgen en waar rook is, is vuur. Dat eist zijn slachtoffers, zoals de recente gebeurtenissen in dit topic maar eens bewijst.

Kortom, tijd voor een andere aanpak.

Kunnen we het daar dan bij houden.

[Verwijderd]

Ik stem voor.

@Q: lijkt dit je niet gewoon het beste? Je wilt het toch ook over de inhoud hebben? Laten we de discussie dan voorlopig begraven, totdat we in het nieuwe topic een goede start kunnen maken. Want dit lijkt nergens op en is niemand mee gebaat.

[Q]

Als we het er al niet over eens kunnen worden dat gekleurd taalgebruik niet thuis hoort in een discussie dan zie ik niet zoveel nut in zo'n topic. Maar ik hou je niet tegen (alsof ik dat kan).

[Verwijderd]

na jaren afwezigheid in deze materie, wil ik de kabeltjes weer is oppakken


heb wat hardware over

ASUS crosshair IV
2 x radeon 5770
4 x 2 gb
phenom II X6 1090T
2x SSD 30Gb
1x SSD 60 Gb
1 xSSD 120 Gb

zover werkt alles

om nu wat HD's die ik hier nog heb liggen te kunnen inzetten dacht ik eraan om freenas te installen
herinner me ineens (slecht geheugen) dat ik daar destijds een geflashed kaartje voor gebruikte.

mijn vraag, zijn er simpele PCI-e kaartjes die ik kan gebruiken (passthrough) ?

- heb eigenlijk maar 2 aansluitingen nodig (geen raid)

* zal je altijd zien, kijk in boven aan de pagina zie ik ineens een ad met dit kaartje :
pricewatch: Conceptronic PCI Express Card SATA 600

en zie staan 'standaard ondersteund door ESXi'
gaat dat werken in mijn opzetje ?

[ Voor 20% gewijzigd door Verwijderd op 23-11-2014 15:05 ]

[Verwijderd]

ASmedia is wel oke.

Maar je hebt natuurlijk geen 2x Radeon 5770 nodig of zoveel SSDs voor een NAS. Je kunt het zonder videokaart doen als je het eenmaal draaiend hebt.

[Verwijderd]

.. nee snap ik van die videokaarten.
ik gaf alleen aan dat ik wat hardware 'over ' had.

ik wil wat verschillende OS en draaien en ik dacht aan freenas met 1 dikke 6 tb disk, als een soort masterbackup van mijn qnap raid.. daarom een klein kaartje, maar die moet dan wel werken in ESXi/freenas

als ik nu zie wat die Intel RAID Controller SASUC8I kosten had ik ze noooooooooooit verkocht

[ Voor 15% gewijzigd door Verwijderd op 23-11-2014 15:57 ]

[Ultra]

Verwijderd schreef op zondag 23 november 2014 @ 11:46:
@Ultra: dat is een open deur; niemand is het daarmee oneens. Het gaat nu juist om de nuancering en relativering van de argumenten. Hoeveel beter is ECC en hoe verhoudt zich dat tot de wenselijkheid cq. noodzakelijkheid ervan voor een ZFS NAS. Pas als je dat helder krijgt uitgelegd aan het grote publiek kun je ongelukjes zoals recent voorkomen.

Het is precies wat Q daarna ook al aanhaalt; als iedereen het ermee eens is dat ECC op zich beter is, hoe kan men dan voor een ander de keuze maken dat ECC niet nodig is in hun situatie? Advies geven is feiten geven, niet risico's wegwuiven (want dat gebeurt helaas, de relativering ontbreekt dan). Dat staat los van een discussie over het kwantificeren van die risico's.

[FireDrunk]

We zijn het toch ook allemaal eens dat Dell en HP hardware in 99 van de 100 gevallen ook superieur is aan ASRock moederbordjes?

Waarom raden we mensen dan nog steeds aan om toch voor een ASRock bordje te gaan...?

Simpel: het is voldoende....

[Ultra]

We?
Superieur wat betreft data-integriteit? Hoe dan?

[Verwijderd]

Alle leuke bordjes voor een kleine zuinige en betaalbare ZFS NAS zijn allemaal non-ECC. Dus je sluit wel enorm leuk spul voor thuis uit als je ECC wilt gaan. Je hebt wel bijvoorbeeld ASRock Avoton bordjes; maar die zijn best prijzig en helemaal niet zo zuinig door de IPMI-chip.

Voor grotere builds is er weinig reden meer om geen ECC te kiezen. Een goedkope build wordt het toch niet, een kleine build wordt het toch niet en een zuinige build wordt het toch niet. Kortom, dan is er weinig reden meer om voor een non-ECC combo te kiezen.

[jan99999]

Zfs heeft als voordeel dat het merkt als er een bitje omvalt, dus ecc is niet nodig, is wel beter als je het kunt betalen, maar als je goedkoop iets wil maken met zfs dan is het niet nodig.

[player-x]

Ultra schreef op zondag 23 november 2014 @ 18:59:
We?
Superieur wat betreft data-integriteit? Hoe dan?

Kan je a.u.b. stoppen met het imho door drammen over ECC, ja we zijn het allemaal met je eens dat het beter is om te hebben, het verschil is dat we niet allemaal denken dat ZFS opeens niet meer goed werkt als we geen ECC hebben.

En de discussie is op zo een dieptepunt gekomen dat vooral het ECC kamp, het andere kamp probeert over te halen van hun gelijk ten kosten van alles, terwijl er nergens harde cijfers zijn die de een of de ander gelijk geeft.

Tot dan sluit ik me aan wat er hier gezegd word in deze blogpost: Why I Chose Non-ECC RAM for my FreeNAS

Kan je niet gewoon wachten totdat CiPHER zijn 'ECC vs Non-ECC' topic klaar heeft, dan kan je daar je hart zoveel luchten als je wilt, en zullen mensen meer berijd zijn om naar je argumenten te luisteren.

[Ultra]

Verwijderd schreef op zondag 23 november 2014 @ 19:12:
Alle leuke bordjes voor een kleine zuinige en betaalbare ZFS NAS zijn allemaal non-ECC. Dus je sluit wel enorm leuk spul voor thuis uit als je ECC wilt gaan. Je hebt wel bijvoorbeeld ASRock Avoton bordjes; maar die zijn best prijzig en helemaal niet zo zuinig door de IPMI-chip.

Voor grotere builds is er weinig reden meer om geen ECC te kiezen. Een goedkope build wordt het toch niet, een kleine build wordt het toch niet en een zuinige build wordt het toch niet. Kortom, dan is er weinig reden meer om voor een non-ECC combo te kiezen.

Ik heb nergens kunnen vinden hoe zuinig een Supermicro X10SLL-S - zonder IPMI - is, maar ik gok 15W of minder in idle. De X10SLL-F zou 18W idle lopen, en die heeft wel IPMI. Ik ga hem niet gebruiken voor mijn komende build(s), omdat ik net een extra PCIe-slot wil hebben, dus ik kan het niet zelf meten.

player-x schreef op zondag 23 november 2014 @ 19:28:
het verschil is dat we niet allemaal denken dat ZFS opeens niet meer goed werkt als we geen ECC hebben.

Dan heb je me en anderen verkeerd begrepen.

[Verwijderd]

Conclusie: dubbel zo onzuinig, driedubbel zo duur (CPU komt er nog bij), nog duurder als je passieve koeling wilt, geen Mini-ITX, geen onboard DC-DC, standaard 6 SATA poorten ipv extra ASmedia chipjes erbij.

Kortom, er zijn genoeg redenen om voor een kleine ZFS NAS juist van die schattige J1900 bordjes te willen. Dan heb je alles wat je nodig hebt: goedkoop, zuinig, passief, ITX, veel SATA en alles in een contact behuizing doordat je geen ATX voeding nodig hebt.

[player-x]

Alle leuke bordjes voor een kleine zuinige en betaalbare ZFS NAS zijn allemaal non-ECC.

een Supermicro X10SLL-S - zonder IPMI

Vind 150+ euro voor een kaal bord zonder CPU nou niet echt betaalbaar alternatief ten opzichte van een ASRock Q1900-ITX bordje.

Ultra schreef op zondag 23 november 2014 @ 19:40:
Dan heb je me en anderen verkeerd begrepen.

Het kan aan mij liggen, maar jullie maken het dan wel heel erg gemakkelijk om verkeert begrepen te worden, want ik lees echt het tegenovergestelde in al jullie post's!

[ Voor 31% gewijzigd door player-x op 23-11-2014 20:09 ]

[Ultra]

Verwijderd schreef op zondag 23 november 2014 @ 19:55:
Conclusie: dubbel zo onzuinig, driedubbel zo duur (CPU komt er nog bij), nog duurder als je passieve koeling wilt, geen Mini-ITX, geen onboard DC-DC, standaard 6 SATA poorten ipv extra ASmedia chipjes erbij.

Kortom, er zijn genoeg redenen om voor een kleine ZFS NAS juist van die schattige J1900 bordjes te willen. Dan heb je alles wat je nodig hebt: goedkoop, zuinig, passief, ITX, veel SATA en alles in een contact behuizing doordat je geen ATX voeding nodig hebt.

Ja, als je een kein schattig NASje wilt. Ik zeg toch nergens dat iemand dat niet mag willen? Alleen zijn mijn wensen en budget blijkbaar anders. Dat was mijn eerdere punt al, vul niet voor mij in wat ik wil, en dat probeer ik ook niet voor een ander te doen (zeg ik er voor de zekerheid bij).
Dat de selectie mobo's zonder ECC-ondersteuning groter is, dat mag duidelijk zijn.

player-x schreef op zondag 23 november 2014 @ 19:57:
Het kan aan mij liggen, maar jullie maken het dan wel heel erg gemakkelijk om verkeert begrepen te worden, want ik lees echt het tegenovergestelde in al jullie post's!

Tja, ik denk niet in kampen, al lijkt het die kant op te gaan intussen. Nogmaals: ik vind dat iedereen voor zichzelf een weloverwegen geinformeerde keus moet kunnen maken, waaronder wel of niet ZFS en wel of niet ECC. Ik ben uit lurkmodus gekomen omdat die vrije keuze in het gedwang kwam.

[nero355]

Dat ECC gezeik elke keer... Beseffen de voorstanders wel dat het best irritant is om een betaalbaar moederbord + CPU combo te vinden die dat überhaupt support ?!

Zelfs mijn 500 € moederbord voor X79 Socket 2011 CPU's zegt vrolijk : Geen ECC en ook geen Registered RAM in mij proppen !!!

Ik geloof dat de G1820 het stiekem wel support, maar het goedkoopste moederbord dat je erbij moet kopen zit al gauw rond de 200 € in plaats van een Z/H/B 97/87/77 gebaseerd moederbord dat je al vanaf 40 € of zo koopt

Dus... hou eens op met dat ECC geroep en als iemand het wel of niet wil ook niet meer over beginnen a.u.b.

[Q]

player-x schreef op zondag 23 november 2014 @ 19:28:
[...]

Kan je a.u.b. stoppen met het imho door drammen over ECC, ja we zijn het allemaal met je eens dat het beter is om te hebben, het verschil is dat we niet allemaal denken dat ZFS opeens niet meer goed werkt als we geen ECC hebben.

En de discussie is op zo een dieptepunt gekomen dat vooral het ECC kamp, het andere kamp probeert over te halen van hun gelijk ten kosten van alles, terwijl er nergens harde cijfers zijn die de een of de ander gelijk geeft.

Tot dan sluit ik me aan wat er hier gezegd word in deze blogpost: Why I Chose Non-ECC RAM for my FreeNAS

Kan je niet gewoon wachten totdat CiPHER zijn 'ECC vs Non-ECC' topic klaar heeft, dan kan je daar je hart zoveel luchten als je wilt, en zullen mensen meer berijd zijn om naar je argumenten te luisteren.

Dag Player-X, nog bedankt voor de post op mijn blog.

Heb je ook goed de updates gelezen van het blog van Brian Moses? Brian maakt een aantal denkfouten in zijn post.

Overigens behoor jij ook tot de groep mensen die niet inhoudelijk wil discussiëren, maar woorden gebruikt als 'stoppen nu' (omdat jij dat roept?) en beticht het andere team van 'doordrammen'.

@Nero355: er zijn genoeg moederborden met ECC support en die zijn meestal wat duurder ja. Het is aan jou hoeveel geld je over hebt om het risico wat ECC geheugen afdekt weg te nemen. Maar doe niet alsof ECC geheugen geen legitiem risico wegneemt.

[ Voor 8% gewijzigd door Q op 24-11-2014 08:52 ]

[FireDrunk]

Zijn reactie:

If you choose non-ECC RAM (like I did, and still would) just make sure you understand what you could be getting into with non-ECC RAM. I still think that risk is minor and I think it’s manageable, but that’s ultimately your decision to make and I wouldn’t fault you for going in either direction.

Hij maakt geen denkfout, dat is zeggen dat iemand geen recht meer heeft op een eigen mening... Dan moeten we ook allemaal verplicht een UPS aanschaffen omdat de kans dat de bliksem inslaat misschien wel even groot is, als een bitflip, maar daar hoor je weer niemand over...

Hij slaat de spijker echt op zijn kop in die blogpost, je moet jezelf *goed* inlezen, en *zelf* bepalen of je data zo belangrijk is dat je ECC wil gebruiken...

Ik (in mijn situatie) vond/vind dat ECC overbodig is (hoewel mijn volgende build het waarschijnlijk wel krijgt, maar niet specifiek voor mijn data pool, eerder voor mijn SSD only VM pool...) omdat het merendeel van mijn data bestaat uit films en TV series... Die kan ik gewoon opnieuw downloaden... Ja dan kan ik net zo goed NTFS, EXT3/EXT4/XFS gebruiken misschien. Dat kan, maar waarom dan *geen* ZFS? Het is altijd beter dan de andere filesystems... De kans op een rotte disk is namelijk groter dan die van rot geheugen...

Geen ZFS gebruiken omdat je denkt dat de kans op rot geheugen groter is dan op een rotte disk is ook een *keuze*, als jij (en dan wijs ik niemand specifiek aan hoor) denkt dat dat zo is, prima... Lekker doen!

Ik denk (in mijn situatie) dat de kans op een rotte sector of een rotte bokkende disk, groter is dan rot geheugen, dus in mijn situatie (90% herdownloadbare data) non-ECC + ZFS een prima beslissing is.

Niet meer, en niet minder...

In mijn volgende build zal ik die overweging gewoon weer opnieuw maken, vooral omdat bijvoorbeeld mijn partner steeds meer belangrijke onderzoeksdata (vanuit universitaire opleiding) op mijn server gaat zetten...

Misschien maak ik er dus nog wel een losse (trage, kleine) NAS naast met ECC... Kan best...

Het doordrammen waar Player-X op doelt, is zeggen dat ECC *ALTIJD* ten *ALLE* tijden verplicht is icm ZFS. Dat is niet zo... Er zijn situaties / use-cases waarbij je prima ervoor kan kiezen om non-ECC te gebruiken, mits je begrijpt welk risico je neemt.

Maar dat geld voor elk stuk hardware en software wat je gebruikt... Een systeem werkt zo goed als de beheerder die er achter zit... PEBKAC is een groter voorkomend fenomeen dan welke hardwarefailure dan ook, laten we dat voorop zetten...

EDIT:
Als we het dus hebben over alles wat kapot kan gaan, is dit een leuk artikeltje:
http://linustechtips.com/...slated-nearly-everything/

Hierin staat (voor zover bekend) van heel veel componenten de gemiddelde AFR

Hierin zie je dus dat Harddisks gemiddeld gezien een 2 * zo hoge AFR hebben in verhouding tot geheugen.
En als je de slechtste harddisk vergelijkt met het beste geheugen zelfs een factor 40 verschil (Kingston geheugen: 0.20%, WD Black harddisk 5%). Natuurlijk is dat allemaal speculatie en miereneuken in de marges.

Maar dat is de kans dat ECC je pool corrupt maakt ook... Het kans percentage daarvan is geen pijl op te trekken

[ Voor 12% gewijzigd door FireDrunk op 24-11-2014 09:21 ]

[Ultra]

FireDrunk schreef op maandag 24 november 2014 @ 09:06:
Het doordrammen waar Player-X op doelt, is zeggen dat ECC *ALTIJD* ten *ALLE* tijden verplicht is icm ZFS. Dat is niet zo... Er zijn situaties / use-cases waarbij je prima ervoor kan kiezen om non-ECC te gebruiken, mits je begrijpt welk risico je neemt.

Daar werd ik van beschuldigd, en dat heb ik nooit gezegd.

[FireDrunk]

Ultra schreef op maandag 24 november 2014 @ 09:22:
[...]

Daar werd ik van beschuldigd, en dat heb ik nooit gezegd.

Ik heb even al je posts achter elkaar gelezen, en ben het inderdaad prima met je eens

[Ultra]

FireDrunk schreef op maandag 24 november 2014 @ 09:25:
[...]

Ik heb even al je posts achter elkaar gelezen, en ben het inderdaad prima met je eens

Ik denk ook dat het probleem is dat de meesten er zo ongeveer hetzelfde over denken, maar zich soms onnauwkeurig uitdrukken, wat een 'leek' verkeerd op kan vatten.

[FireDrunk]

Dat gebeurd hier wel vaker hoor... (Ik ben er zelf ook wel eens schuldig aan, geef ik eerlijk toe).

Ik zie het vaak als de kosten van een "passie" hebben

[player-x]

Ultra schreef op maandag 24 november 2014 @ 09:22:
Daar werd ik van beschuldigd, en dat heb ik nooit gezegd.

Nee, met door drammen bedoel ik dat het nog steeds over ECC hebben, terwijl nadrukkelijk en herhaaldelijk is gevraagd deze discussie tijdelijk op te schorten, en deze veder te voeren in een nieuw te maken topic dat daar speciaal voor bedoelt is.

[Ultra]

player-x schreef op maandag 24 november 2014 @ 09:54:
[...]

Nee, met door drammen bedoel ik dat het nog steeds over ECC hebben, terwijl nadrukkelijk en herhaaldelijk is gevraagd deze discussie tijdelijk op te schorten, en deze veder te voeren in een nieuw te maken topic dat daar speciaal voor bedoelt is.

Ik weet niet waarom je mij quote. Ik reageerde op de interpretatie van FireDrunk, die blijkbaar niet klopte.

[Q]

@Firedrunk, onder het kopje 'my Thoughts', met name punt 2 en punt 4 zijn onjuist. Met name punt 4. is waar Andrew Galloway een weerwoord op heeft geschreven. http://nex7.blogspot.com/...ecc-ram-great-debate.html

Dan iets anders: disks gaan vaker stuk dan geheugen maar daar beschermt legacy RAID ook tegen. Echter, ZFS beschermt beter, bij een RAIDZ2/RAID6 waarbij een 3e disk faalt (al heel kleine kans) kan ZFS het verschil betekenen tussen alle data weg of slechts een paar files.

Het is daarom in mijn ogen niet juist om het risico op een defecte disk uit te zetten tegen het risico op rot geheugen, zoals jij hier doet. Als je de juiste risico's tegen elkaar uitzet (3e disk failure in RAIDZ2/RAIDZ6), dan denk ik dat de risico's waar ZFS tegen beschermt (tov reguliere RAID) veel kleinere zijn qua kans, en waarschijnlijk meer op het niveau zit van de kans op rot geheugen, met bijbehorende impact.

Edit, als je er zo naar kijkt en je vind het redelijk als mensen er voor kiezen om toch geen ECC te gebruiken, dan met dezelfde redenatie, is er ook geen issue als mensen van ZFS afzien.

[ Voor 9% gewijzigd door Q op 24-11-2014 12:19 ]

[FireDrunk]

Oh zeker. Het zal mij jeuken of mensen ZFS gebruiken. Ik lees geregeld hier verhalen over mensen die NTFS icm RAID0 gebruiken over echt veel schijven (4+). Als je daar zelf met een weloverwegen gedachte voor kiest, be my guest, ik kan er niet wakker van liggen...

Ik weerleg het alleen op mijn situatie, en dat probeer ik hopelijk ook duidelijk te verwoorden in mijn posts.

Ik snap je punt wel hoor, kansen zijn niet altijd verenigbaar tot 1 getal, of goed vergelijkbaar, maar als we zo ontzettend diep op de kansberekeningen gaan kijken om te zeggen of iets wel of niet 'moet' of 'aan te raden is', zijn we dan niet gewoon met zijn allen koffiedik aan het kijken of in een kristallen bol aan het koekeloeren om te kijken wie er gelijk heeft?

Ik ontkracht niemands mening, ik zeg alleen dat mensen ten allen tijde hun eigen keuzes moeten maken als het gaat over de veiligheid van hun data.

In mijn situatie betekend dat letterlijk: Ik geloof dat mijn pool eerder tegen een reallocted aan komt, dan tegen bitrot. Ik zeg niet dat dat op letterlijke getallen gebaseerd is(dat kan namelijk helemaal niet, want dan zou ik de AFR van al mijn componenten moeten meenemen), ik weet alleen namelijk NU al dat mijn schijven slecht zijn.

Mijn huidige Seagate HDD.15 4TB's hebben namelijk NU op DIT MOMENT pending sectors...
Dus op dit moment weet ik heel zeker dat mijn harddisks in een slechtere staat zijn dan mijn geheugen. En in MIJN situatie weet ik dus zeker dat ZFS momenteel een betere keuze is dan NTFS/EXT3-4/XFS.

In de toekomst, als ik misschien 10*4TB ofzo zou gaan draaien, weet ik eigenlijk 99% zeker dat ik naar ECC zou gaan...

(Absoluut objectief bedoeld, en geenzins negatief:) Jij probeert een homogene oplossing te vinden voor het probleem, jij wil dat iedereen met zijn neus dezelfde kant op staat (is mijn gevoel).
IK denk niet dat we dat in deze discussie moeten proberen, want daar is het een veel te ingewikkelde discussie voor met al die AFR's / Kansberekeningen...

Als mensen die discussie echt op het allerdiepste niveau willen voeren, vindt ik dat zeker prima, en ik zou er ook echt graag aan mee doen... Daar kan ik vast nog wat leren.

Maar ik vind het onterecht om als de discussie nog niet op zo'n diep niveau EN specifiek voor het systeem in kwestie waar de gebruiker voor kiest (dus letterlijk de KIT list van de server) is gevoerd. Om dan een waardeoordeel te hangen aan de keuze van de gebruiker ( hij is "niet goed bezig" / "dom" om niet voor ECC te kiezen...)

We moeten hier met zijn allen objectief blijven (en dat geldt ook zeer zeker voor CiPHER hoor, maar ook voor mij, en ook voor iedereen hier).

Wij moeten toetsbare feiten vertellen, en kunnnen (mits onderbouwt) advies geven. Maar ik ben niet van mening dat wij altijd advies moeten geven tegen de zin van een gebruiker in omdat het de 'perfecte' oplossing is. Het is aan de eindgebruiker om te beslissen of hij 100% veiligheid wil, en niet aan ons.

Dat wil nog steeds niet zeggen dat jij niet mag roepen dat ECC beter is, dat mag je van mij 100x per dag roepen... Het gaat er meer om dat iedereen hier verhit tegen elkaar gaat lopen roepen dat de andere kant ongelijk heeft, en dat is gewoon niet waar... Er zijn gewoon meerdere kanten aan het verhaal... En het blijft een keuze... Net als het dragen van je autogordel

Eigenlijk is de samenvatting van OpenZFS' Wiki prima:

Background

Ordinary background radiation will randomly flip bits in computer memory, which causes undefined behavior. These are known as "bit flips". Each bit flip can have any of three possible consequences depending on which bit is flipped:

Bit flips can have no effect.
Bit flips that have no effect occur in unused memory.

Bit flips can cause runtime failures.
This is the case when a bit flip occurs in something read from disk.
Failures are typically observed when program code is altered.
If the bit flip is in a routine within the system's kernel or /sbin/init, the system will likely crash. Otherwise, reloading the affected data can clear it. This is typically achieved by a reboot.

It can cause data corruption.
This is the case when the bit is in use by data being written to disk.
If the bit flip occurs before ZFS' checksum calculation, ZFS will not realize that the data is corrupt.
If the bit flip occurs after ZFS' checksum calculation, but before write-out, ZFS will detect it, but it might not be able to correct it.

It can cause metadata corruption.
This is the case when a bit flips in an on-disk structure being written to disk.
If the bit flip occurs before ZFS' checksum calculation, ZFS will not realize that the metadata is corrupt.
If the bit flip occurs after ZFS' checksum calculation, but before write-out, ZFS will detect it, but it might not be able to correct it.
Recovery from such an event will depend on what was corrupted. In the worst, case, a pool could be rendered unimportable.
All filesystems have poor reliability in their absolute worst case bit-flip failure scenarios. Such scenarios should be considered extraordinarily rare.

[ Voor 21% gewijzigd door FireDrunk op 24-11-2014 12:49 ]

[TripleM]

Ik ben mijn opties voor een nieuwe NAS toch nog even aan het heroverwegen. In het bijzonder de mogelijkheden qua CPU. Ik ken de verschillen toch niet echt goed genoeg vrees ik.

Mijn NAS gaat niet transcoden, maar wel SABnzbd draaien. Mijn oude Synology (DS210j, single core 800 Mhz CPU volgens mij) stond bij het uitpakken/repareren van een grote file (>10GB) soms urenlang uit z'n pan te gaan, dan kon ik amper nog wat met het kreng. Daar heb ik niet zo'n trek meer in.

Qua OS ben ik er nog niet uit, eigenlijk overweeg ik om lekker makkelijk Windows te draaien. M'n mediaspeler is ook een eenvoudig Windows 8 bakkie (AMD Fusion E-350, 4 GB RAM) met XBMC erop. Maar ik ben handig genoeg om met een *NIX optie aan de slag te gaan.

Aanvankelijk heb ik gekeken naar CPU's van 2 Ghz en hoger, en een TDP van 40W max. Dan kom ik bij opties als een Intel Celeron G1820T voor socket 1150, maar ik las hier ook over opties als de J1900 (en ik zag ook de J2900?).

En dan is er natuurlijk altijd nog de mogelijkheid om m'n huidige mediaspeler tot NAS te bombarderen, en een ander device te zoeken om XBMC op te draaien?

[MTDjassen]

Correct me if I'm wrong, maar volgens mij kan je voor je NAS beter een dedicated OS erop knallen, anders heb je de overhead van Windows er ook nog bij als hij (bv) newsgroup packages aan het uitpakken is. Verder zou ik dan eerder voor een nieuwe build met FreeNAS (o.i.d.) gaan dan je mediaplayer ombouwen, omdat de functionaliteit van een mediaplayer en een NAS dermate verschillend zijn dat de kans groot is dat de hardware in je mediaplayer weer niet zo lekker ligt bij NAS-functie (en andersom). Ik zelf draai zo'n J1900 onboard SOC bordje met 3*2TB met SABnzbs, transmission, plex, couchpotato en sickbeard en heb geen last van slechte connectivity. Gebruik verder een raspberry pi als XBMC player, maar dat doet niet echt terzake.

[FireDrunk]

Mja, ik kan wel begrijpen dat je liever wat meer power neemt als het gaat om PAR/UNRAR features... In mijn NAS heeft een flinke tijd een G1610 (voorloper van de G1820) gezeten, en die kon dat prima aan, maar de i5 die er nu in zit is wel echt merkbaar sneller...(logisch natuurlijk) Het is maar wat je belangrijk vindt.

Ik denk dat je met IONICE een heel eind komt om je systeem bereikbaar/responsief te houden terwijl hij met PAR/UNRAR bezig is, maar als ik zou mogen kiezen, liever een G1820 dan een J1900... Dat is echt al een flink verschil... En kijk je niet mis op een G1820, dat zijn nog best snelle CPU's hoor!

[ Voor 3% gewijzigd door FireDrunk op 24-11-2014 13:56 ]

[Q]

@Firedrunk, natuurlijk gaat het er omdat mensen zelf hun keuzes maken, maar dan wel op basis van de juiste informatie en daar is gesteggel over.

Met het vetgedrukte stukje tekst uit de quote van het OpenZFS wiki, lijk je te suggereren dat OpenZFS indirect ook aangeeft dat die kans zo klein is, dat ze niet echt relevant is. En dan zou je kunnen gaan denken dat ECC geheugen niet zo'n big deal is.

Maar misschien is het wel goed om jouw quote in het juiste perspectief te plaatsen, want dit staat er boven (OpenZFS Wiki):

ECC Memory

Bit flips can have fairly dramatic consequences for all computer filesystems and ZFS is no exception. No technique used in ZFS (or any other filesystem) is capable of protecting against bit flips. Consequently, ECC Memory is highly recommended.

Late edit: ik snap dat je punt is dat de kans op het verlies van een pool volgens OpenZFS niet zo groot is en dat is redelijk, de kans is groter dat je last krijgt van silent data corruptie. Is de kans op het verlies van een ZFS file system door rot geheugen vergelijkbaar met de kans op een 3e disk faillure in een RAIZ2/RAID6?

[ Voor 29% gewijzigd door Q op 24-11-2014 15:42 ]

[MTDjassen]

Hups en we zijn weer terug bij ECC vs non-ECC gedoe terwijl er al duizend keer gezegd is dat er een dedicated topic komt waar we alles weer met z'n allen netjes gaan herhalen. Laten we dit topic in z'n eer herstellen en dat is mensen (zoals TripleM) adviseren over hun NAS-systeem, deze versnipperde welles/nietes discussie bloat alleen maar dit topic zonder dat er echt iemand mee geholpen is.

[TripleM]

MTDjassen schreef op maandag 24 november 2014 @ 13:42:
Correct me if I'm wrong, maar volgens mij kan je voor je NAS beter een dedicated OS erop knallen, anders heb je de overhead van Windows er ook nog bij als hij (bv) newsgroup packages aan het uitpakken is. Verder zou ik dan eerder voor een nieuwe build met FreeNAS (o.i.d.) gaan dan je mediaplayer ombouwen, omdat de functionaliteit van een mediaplayer en een NAS dermate verschillend zijn dat de kans groot is dat de hardware in je mediaplayer weer niet zo lekker ligt bij NAS-functie (en andersom).

Maar in mijn geval is mijn mediaspeler ook maar een generiek (zelfbouw) Windows bakkie, waar ik dan toevallig alleen XBMC op draai en het daarom mijn mediaspeler noem. Vandaar dat ik dacht dat dat zelfde bakkie ook vast wel SABnzbd zou kunnen draaien. Want puur het serveren van bestanden kan met ieder platform vast prima.

Ik zelf draai zo'n J1900 onboard SOC bordje met 3*2TB met SABnzbs, transmission, plex, couchpotato en sickbeard en heb geen last van slechte connectivity. Gebruik verder een raspberry pi als XBMC player, maar dat doet niet echt terzake.

Goed om te weten, dankjewel. Ik zag ook de hoger geklokte J2900 langskomen, beetje meer power voor repareren/unrarren is dan misschien nog wel geinig. Het prijsverschil is minimaal.

Ik ken die hele SoC markt sowieso slecht, dus als iemand weet wat recente/interessante opties zijn op dat vlak. Die 1037U misschien? Ik las iets over dat die wel weer vervangen zou worden door een Ivy Bridge tegenhanger, maar welke zou dat dan worden/zijn? (edit: de E3845?)

[player-x]

Goede betaalbare home server

#	Product	Prijs	Subtotaal
1	Intel Celeron G1820 Boxed	€ 30,50	€ 30,50
1	Asus B85M-E	€ 62,-	€ 62,-
1	Hitachi Travelstar 5K1000, 1TB	€ 51,96	€ 51,96
1	Codegen Q3343-A11 <-- compact met veel HDD bays	€ 40,40	€ 40,40
1	Scythe Mugen 4 <-- Optie als je een erg stil systeem wildt	€ 32,50	€ 32,50
1	Crucial Ballistix BLS2CP4G3D1609DS1S00CEU	€ 62,95	€ 62,95
1	be quiet! System Power 7 300W	€ 30,95	€ 30,95
-	ECC alternatieven	-	-
1	Elixir M2F4GH64CB8HB6N-DI	€ 34,88	€ 34,88
1	Intel Server Board S1200V3RPS	€ 167,50	€ 167,50
1	ASRock C226 WS	€ 176,27	€ 176,27

Moederborden
Zoek een moederbord dat echt alles heeft wat je nu en misschien later zoekt, van belang is dat hij vooral degelijk is, en denk na wat voor een uitbreidingssloten je eventueel nodig hebt. (raid controller en/of TV kaarten)
Tip: kies echter wel een zo een simpel mogelijke mobo model uit met alleen de opties die je nodig hebt, dergelijke mobo's verbruiken meestal minder dan de luxere modellen met onodigeveel opties.

Harddisks/SSD's
Ten eerste zou ik een 2.5'' van 250GB of grotere als als OS en download HDD.

Het is aan te bevelen om een 2.5'' download/OS schijf te hebben ipv 3.5'' waar je tijdelijk je downloads opslaat totdat je ze later kan ordenen, voordelen, zijn dat niet de hele array hoeft op te spinnen tijdens download, en 2.5'' is lekker zuinig, maar nog steeds snel genoeg voor downloads usenet of Torrent.

Met de gebruikte kast heb je een lekker klein compact systeempje dat niet te veel verbruikt.

[nero355]

FireDrunk schreef op maandag 24 november 2014 @ 13:56:
En kijk je niet mis op een G1820, dat zijn nog best snelle CPU's hoor!

Zijn inderdaad best snel : Een oude Core 2 Quad zoals de Q8200 blazen ze zo voorbij in de meeste benchmarks en dat was echt geen slechte CPU !!

Ook voldoet de boxed koeler 99% van de tijd eigenlijk gewoon prima, vooral in een HTPC waar de videokaart het drukker heeft dan de CPU meestal : Ik hoor die boxed koeler nooit!
In een NAS zal je hem alleen misschien horen tijdens het uitpakken of zo... misschien zelfs dan niet. Daarom zou ik ook niet gelijk een andere koeler erop schroeven. Eerst met de boxed koeler testen een tijdje

[BartNL]

FireDrunk schreef op maandag 24 november 2014 @ 09:06:
Hierin zie je dus dat Harddisks gemiddeld gezien een 2 * zo hoge AFR hebben in verhouding tot geheugen.

en daarmee rechtvaardig je dan de noodzaak van ZFS omdat harddisks zo onbetrouwbaar zijn en het niet nodig zijn van ECC

[player-x]

BartNL schreef op maandag 24 november 2014 @ 20:12:
en daarmee rechtvaardig je dan de noodzaak van ZFS omdat harddisks zo onbetrouwbaar zijn en het niet nodig zijn van ECC

Wat jij nu doet is echt Trollen, kan je ******* niet even wachten totdat CiPHER zijn ECC topic klaar heeft.

De ECC discussie is al ver genoeg uit de hand gelopen, zonder dat jij een nieuwe emmer benzine op het vuur gooit..

FireDrunk laat je niet uit je tent lokken, net als alle andere hopelijk ook nu eindelijk begrijpen dat dit niet de plaats er voor is op het moment.

Edit:

Q schreef op maandag 24 november 2014 @ 21:34:
Why so serious? Waarom zo emotioneel?

Ben niet boos of emotioneel, wat ik wel ben is ge-irriteert over het door zaniken over een onderwerp waar een mod en verscheidende andere hebben gevraagd over te stoppen voor nu tot het nieuwe topic er is.

Als je dat niet niet kan begrijpen heb je een panzer stalen plaat voor je kop waar letterlijk geen enkele idee of gevoelens wat normale omgang met andere is door komt, en je niet jee standpunt meer aan het verdedigen bent, maar je nu puur aan Trollen bent.

Want anders zou je nooit zo een trollige opmerking maken als je nu doet.

[ Voor 36% gewijzigd door player-x op 25-11-2014 14:17 ]

[Q]

Why so serious? Waarom zo emotioneel?

[ Voor 42% gewijzigd door Q op 24-11-2014 21:37 ]

[Verwijderd]

Q schreef op maandag 24 november 2014 @ 21:34:
Why so serious? Waarom zo emotioneel?

Dit topic is bedoeld voor adviezen hulp bij het bouwen van een DIY NAS. Eeen wellis nietes discussie over ECC draagt hier niets bij. je moet de meeste posts al overslaan om iets over DIY NAssen te lezen en volgen

Een extern topic over ECC waarnaar verwezen kan worden voor de vraag wel of geen ECC zou een verademing zijn.

Overigens is er wel iets wat ik mis bij veel bouwvoorstellen. Het doel van de NAS. Het maakt (niet alleen voor ECC) een hoop uit of je een NAS wilt om automatisch mee te downloaden en te streamen naar je apparatuur, voor de opslag/backup van uiters belangrijke infomatie die je altijd/vaak snel beschikbaar moet hebben. of wellicht beide. Wat je budget is en wat je tolerantie voor herrie, een stroomrekening is. Meestal staat er wel een budgetje bij.

Voor de NAS die ik nu aan het bouwen ben (de onderdelen druppelen binnen) is budget geen issue, dan doe ik een maandje langer over het bouwen. Maar aangezien hij gaat dienen als een automatische backup target voor een aantal notoire computer analfabeten die er wel het hele familie album op zullen zetten wat onvervangbaar is, is mijn belangrijkste issue betrouwbaarheid van de NAS en de backup solution voor de NAS. Bijzaak is dat ik een tweede zpool wil voor een plex server en dat ik deze eigenlijk wil draaien (maar dat is termijn planning) door twee gevirtualiseerde servers. Vooralsnog doe ik het met 1 server en jails.

Al mijn hardware is daarop afgestemd en dus server hardware, en gezien de eisen is voor mij ECC geen vraag maar een zekerheidje.

[Verwijderd]

Verwijderd schreef op maandag 24 november 2014 @ 22:24:
[...]
..

Overigens is er wel iets wat ik mis bij veel bouwvoorstellen. Het doel van de NAS. Het maakt (niet alleen voor ECC) een hoop uit of je een NAS wilt om automatisch mee te downloaden en te streamen naar je apparatuur, voor de opslag/backup van uiters belangrijke infomatie die je altijd/vaak snel beschikbaar moet hebben. of wellicht beide. Wat je budget is en wat je tolerantie voor herrie, een stroomrekening is. Meestal staat er wel een budgetje bij.

en in welke behuizing je eea gaat bouwen .. staat er ook meestal niet bij

[Q]

Wat echt leuk / nuttig zou zijn voor de DiY bouwers is om een stuk of 5 verschillende builds te tonen die mensen ook daadwerkelijk gebouwd hebben en dat ze dus uit een soort 'menu' kunnen kiezen om inspiratie op te doen om zelf iets te maken. Van klein simple en goedkoop, tot iets duurder met betere componenten en capaciteit en 19"? formfactor. Alles compleet met specs inclusief running cost (stroom).

[ Voor 7% gewijzigd door Q op 25-11-2014 12:50 ]

[FireDrunk]

Dat hebben we ooit geprobeerd in het Grote ZFS topic, in het Nieuwe Zuinige Server topic, Het Energiezuinige Topic, en Het Grote 20TB+ NAS Topic.

Take your pick... Als we het hier ook nog moeten doen

[Nindustries]

Heb ooit bijna een website willen maken voor specifiek dat doel, leek me wel cool.
Waar dan ook gebruikers ratings en comments konden geven.

Ahh, free time..

[Verwijderd]

heb 2 van die kaartjes besteld
ze leken mij hetzelfde als de Conceptronic PCI Express Card SATA 600

Als ik nu is die 2 kaartjes in passthrough kan zetten onder ESXi naar freenas.. ben ik voor 19,- klaar

[Nindustries]

Verwijderd schreef op dinsdag 25 november 2014 @ 14:06:
Als ik nu is die 2 kaartjes in passthrough kan zetten onder ESXi naar freenas.. ben ik voor 19,- klaar

Je moet juist de AsMedia driver includen in ESXi, heb dat kaartje hier ook liggen.

Dit ligt buiten de scope van dit topic, maar toch een linkje voor borroz.

[ Voor 25% gewijzigd door Nindustries op 25-11-2014 14:25 ]

[Verwijderd]

ah.. dat heb ik nog nooit gedaan.
ik dacht, prik ze in het mobo en ESXi 'ziet' ze.. maar ik moet dus eerst de drivers installen.
heb gelukkig nog een paar weken om me in te lezen

[Raven]

Leesvoer: http://www.v-front.de/p/esxi-customizer.html Kun je de iso mee customizen. Voorbeeldje met LAN-driver: http://www.ivobeerens.nl/...i-5-whitebox-nic-support/

ESXi bevat helaas maar een beperkt aantal drivers.

[ Voor 62% gewijzigd door Raven op 25-11-2014 14:34 ]

[Neptunus]

ECC vs non-ECC RAM and ZFS

[ Voor 176% gewijzigd door Neptunus op 25-11-2014 14:34 ]

[Verwijderd]

Raven schreef op dinsdag 25 november 2014 @ 14:31:
Leesvoer: http://www.v-front.de/p/esxi-customizer.html Kun je de iso mee customizen. Voorbeeldje met LAN-driver: http://www.ivobeerens.nl/...i-5-whitebox-nic-support/

ESXi bevat helaas maar een beperkt aantal drivers.

tnx !

en Nindustries ook

[ Voor 3% gewijzigd door Verwijderd op 25-11-2014 14:44 ]

[IceTeaGX]

Als je ze in passtrough gaat zetten, heb je eigenlijk geen drivers nodig.
(alleen zien dat je niet met PCI(e) bridges zit)

[FireDrunk]

Ik heb negatieve ervaringen met die kaartjes icm passthrough, ze wilden wel in passthrough, maar mijn kaartjes waren voorzien van een BIOS (waardoor je ervan kon booten). Die BIOS vond VT-d helemaal niet leuk, waardoor de kaartjes wel gezien werden in de Guest VM, maar niet wilden starten.

Ik moet daar ooit ook nog eens tijd aan spenderen, heb ook nog 2 van die kaartjes liggen.
Misschien kan je de BIOS er wel af flashen, dan zouden ze gewoon moeten werken denk ik.

[TripleM]

Ik neem m'n advies wel gewoon in stukjes Ik ben nu op zoek naar een geschikte behuizing, en dat valt nog niet mee. Ik wil 2 x 3.5" schijven gebruiken voor de opslag, en 1 x 2.5" (SSD) voor boot/download/temp. Maar ook al komt de NAS in de meterkast te staan (of hangen), als het even kan wil ik niet een behuizing van tig liter als die ruimte helemaal niet wordt gebruikt. En de kasten worden al snel behoorlijk groot.

Ik zag bv. een mooie Streacom (pricewatch: Streacom F1CWS Evo Zilver), maar die kan ofwel 3 x 2.5" hebben, of 1 x 2.5" en 1 x 3.5". Da's net te weinig. Verder wel supermooie behuizingen.

Wat eventueel nog een optie is, is om ergens een los rack oid te scoren waar de schijven in komen (liefst zodat ik ze akoestisch kan ontkoppelen), en dat rack en het moederbordje dan gewoon tegen de muur te schroeven (al dan niet beschermd door een plexiglas plaatje).

Deze zou werken, al kan ik dan niet de schijven afzonderlijk akoestisch ontkoppelen:



http://www.moddiy.com/pro...-Rack-Tray-%28Y4F%29.html

Of als iemand wel een compacte case weet waar 2 x 3.5" en 1 x 2.5" in kan, graag!

(-edit- De http://tweakers.net/product/322746/streacom-fc5-ws-evo/ is prachtig, maar weer erg duur)

[ Voor 3% gewijzigd door TripleM op 25-11-2014 15:41 ]

[Ultra]

Ik ga mijn oude NAS, met slechts 1x 1.5TB vervangen door:

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1231 V3 Boxed	€ 234,-	€ 234,-
1	Intel Server Board S1200V3RPS	€ 167,50	€ 167,50
4	WD Green WD40EZRX	€ 136,-	€ 544,-
1	WD Green WD40EZRX	€ 0,-	€ 0,-
1	Scythe Kotetsu	€ 27,50	€ 27,50
1	Crucial Ballistix Tactical BLT2C8G3D1608ET3LX0CEU	€ 132,95	€ 132,95
1	Conceptronic PCI Express Card SATA 600	€ 24,02	€ 24,02
1	Seasonic G-Serie 450 Watt	€ 67,95	€ 67,95
1	Crucial MX100 128GB	€ 60,91	€ 60,91
1	Crucial MX100 512GB	€ 181,30	€ 181,30
1	Antec Solo	€ 0,-	€ 0,-
	Virtuele game pc:
1	MSI Radeon R9 270X GAMING 2G	€ 171,-	€ 171,-
1	Asus Xonar DGX	€ 30,-	€ 30,-
Bekijk collectie Importeer producten		Totaal	€ 1.667,69

Hierop ga ik onder andere een ZFS-on-Linux en Windows virtueel draaien dmv Xen(Server). Dat zal tijdelijk zijn, want ik kan me niet voorstellen dat ik de geluidsproductie acceptabel vind. Maakt niet uit, ik wil er gewoon eens mee spelen. Als de hardware me bevalt koop ik hetzelfde mobo, geheugen en tragere CPU om NAS en desktop pc weer uit elkaar te kunnen trekken. De NAS kan dan herrie gaan maken op een geschiktere plek.

Vanwege schijnbaar slechte compatibiliteit met Xen(Server) wil ik geen Marvell HBA(chip), en veel poorten heb ik niet nodig, dus een ASmedia kaartje. De onboard controller gaat in passthrough.

Voor deze build heb ik geen IPMI/KVM nodig, maar ik ga op termijn een kopie (qua hardware en data) op een andere locatie neerzetten. Remote beheer is dan wel nuttig. Als ik de documentatie van Intel goed begrijp heeft de S1200V3RPS wel remote KVM, alleen geen mogelijkheid voor een dedicated IPMI NIC.

De vijf 4TB disks gaan in RAIDZ2. De 2^n-regel gaat niet op vanwege compressie.

offtopic:
De Nvidia-kaarten voor consumenten werken niet via PCI passthrough, vandaar geen GTX 970.

[thibautb]

eigenlijk voor gewoon nas zou je met een pentium g3240 al zeker goed komen, want zo een xeo is misschien toch wel een beetje overkill, ook voor gaming pc, dan zou ik toch gewoon een van de high end i3's kopen, die ondersteunen ook ecc.

[matty___]

..

[ Voor 196% gewijzigd door matty___ op 25-11-2014 16:41 ]

[Pantagruel]

Ultra schreef op dinsdag 25 november 2014 @ 15:44:
Ik ga mijn oude NAS, met slechts 1x 1.5TB vervangen door:

#	Product	Prijs	Subtotaal
1	Intel Xeon E3-1231 V3 Boxed	€ 234,-	€ 234,-
1	Intel Server Board S1200V3RPS	€ 167,50	€ 167,50
4	WD Green WD40EZRX	€ 136,-	€ 544,-
1	WD Green WD40EZRX	€ 0,-	€ 0,-
1	Scythe Kotetsu	€ 27,50	€ 27,50
1	Crucial Ballistix Tactical BLT2C8G3D1608ET3LX0CEU	€ 132,95	€ 132,95
1	Conceptronic PCI Express Card SATA 600	€ 24,02	€ 24,02
1	Seasonic G-Serie 450 Watt	€ 67,95	€ 67,95
1	Crucial MX100 128GB	€ 60,91	€ 60,91
1	Crucial MX100 512GB	€ 181,30	€ 181,30
1	Antec Solo	€ 0,-	€ 0,-
	Virtuele game pc:
1	MSI Radeon R9 270X GAMING 2G	€ 171,-	€ 171,-
1	Asus Xonar DGX	€ 30,-	€ 30,-
Bekijk collectie Importeer producten		Totaal	€ 1.667,69

Hierop ga ik onder andere een ZFS-on-Linux en Windows virtueel draaien dmv Xen(Server). Dat zal tijdelijk zijn, want ik kan me niet voorstellen dat ik de geluidsproductie acceptabel vind. Maakt niet uit, ik wil er gewoon eens mee spelen. Als de hardware me bevalt koop ik hetzelfde mobo, geheugen en tragere CPU om NAS en desktop pc weer uit elkaar te kunnen trekken. De NAS kan dan herrie gaan maken op een geschiktere plek.

Vanwege schijnbaar slechte compatibiliteit met Xen(Server) wil ik geen Marvell HBA(chip), en veel poorten heb ik niet nodig, dus een ASmedia kaartje. De onboard controller gaat in passthrough.

Voor deze build heb ik geen IPMI/KVM nodig, maar ik ga op termijn een kopie (qua hardware en data) op een andere locatie neerzetten. Remote beheer is dan wel nuttig. Als ik de documentatie van Intel goed begrijp heeft de S1200V3RPS wel remote KVM, alleen geen mogelijkheid voor een dedicated IPMI NIC.

De vijf 4TB disks gaan in RAIDZ2. De 2^n-regel gaat niet op vanwege compressie.

offtopic:
De Nvidia-kaarten voor consumenten werken niet via PCI passthrough, vandaar geen GTX 970.

Erhhmm quote vanuit t blogje dat je aanhaalt:

The strongest valid recommendation based on exact fitting of blocks into stripes is the following: If you are using RAID-Z with 512-byte sector devices with recordsize=4K or 8K and compression=off (but you probably want compression=lz4): use at least 5 disks with RAIDZ1; use at least 6 disks with RAIDZ2; and use at least 11 disks with RAIDZ3.

Maar voor ZFS gerelateerde zaken is er een eigen thread

Gezien de gekozen cpu en t board zou je naar ECC UDIMM moeten kijken.

[matty___]

Volgens mij gaat het om 4k disks en standaard recordsize van 128k.

[ABD]

Ruim een jaar geleden was mijn oude Netgear RND2000 al vol en wilde ik een DIY NAS gaan bouwen. Ik had helaas het lumineuze idee om die rondom van een fanloos AMD Kabini ITX bordje te bouwen, omdat ik er ook XBMC op wilde draaien, om zo mijn slurpende PC de woonkamer uit te bonjouren. Welnu, Kabini ITX bordjes zijn er nauwelijk verschenen, en fanloze al helemaal niet en nu komt Beema eraan, en daar kan ik ook weer op gaan wachten en zo wordt het 2018 voordat ik een nieuwe NAS in huis heb.

Hoe dan ook, ik wil een NAS bouwen met SABNZBd, Sickbeard, Coachpotato, torrentclient, mailserver, ftp server en XBMC. Ik dacht eraan om XBMCbuntu/KodiBuntu en ZFS te gaan installeren, maar het zou ook FREENAS en Plex kunnen worden, al gaat mijn voorkeur uit naar XBMC/Kodi. Het idee is om van USB stick te booten, om zo een 4e HDD aan te kunnen sluiten. Dit is mijn gekozen setup:

#	Product	Prijs	Subtotaal
1	ASRock QC5000-ITX/WiFi	€ 72,95	€ 72,95
4	Seagate Desktop HDD, 4TB	€ 135,95	€ 543,80
1	Fractal Design Node 304 Zwart	€ 64,95	€ 64,95
1	Sandisk Extreme USB 3.0 Flash Drive 16GB Zwart	€ 16,26	€ 16,26
1	Crucial Ballistix Tactical BLT2C4G3D1608ET3LX0CEU	€ 66,95	€ 66,95
1	be quiet! System Power 7 300W	€ 30,95	€ 30,95
Bekijk collectie Importeer producten		Totaal	€ 795,86

Het idee is om dat kleine fannetje eraf te halen, wanneer dat ding teveel geluid maakt. Ik ga dan een ander koelblok monteren en eventueel meer koeling in de Node 304 hangen. Ik zie nergens in dit draadje problemen met de ASMedia ASM1061 controller, dus ik neem aan dat dat snor zit. Een Intel variant van dit bordje met de Celeron J1900/2900 is eventueel een optie.

Ik denk post deze setup nog even voor verificatie voor ik de bestelling plaats, misschien krijg ik nog nuttige opmerkingen.

[Verwijderd]

Hoe denk je een andere heatsink te monteren op dat bordje? Want je hebt geen socket alleen through-holes. Je kunt ook Kabini overwegen die bordjes hebben vaak een passieve heatsink. Daar heb je IMO meer aan dat je gelijk iets goeds koopt. Want die kleine fannetjes vind ik maar niks.

[Ultra]

Pantagruel schreef op dinsdag 25 november 2014 @ 16:43:
Maar voor ZFS gerelateerde zaken is er een eigen thread

Ja, dat blogje heb ik daar al eerder gepost. Leek me wel informatief om te vermelden welk FS ik ga gebruiken. De reden om een 5 ipv 6 disk RAIDZ2 te gebruiken had niet gehoeven. Je leest het niet goed overigens:

The strongest valid recommendation based on exact fitting of blocks into stripes is the following: If you are using RAID-Z with 512-byte sector devices with recordsize=4K or 8K and compression=off (but you probably want compression=lz4): use at least 5 disks with RAIDZ1; use at least 6 disks with RAIDZ2; and use at least 11 disks with RAIDZ3.

Pantagruel schreef op dinsdag 25 november 2014 @ 16:43:
Gezien de gekozen cpu en t board zou je naar ECC UDIMM moeten kijken.

Dat wist ik . Geen idee hoe dat erin geslopen is. Thx.

[ABD]

Verwijderd schreef op dinsdag 25 november 2014 @ 17:36:
Hoe denk je een andere heatsink te monteren op dat bordje? Want je hebt geen socket alleen through-holes. Je kunt ook Kabini overwegen die bordjes hebben vaak een passieve heatsink. Daar heb je IMO meer aan dat je gelijk iets goeds koopt. Want die kleine fannetjes vind ik maar niks.

Ik zie vier gaten plus nog 2 waar die heatsink mee vastgezet is, ik moet wel wat kunnen verzinnen. En wellicht is de geleverde heatsink voldoende, want er zitten twee 92mm fans en een 140mm fan in die Node 304. Ik vind die kleine fannetjes ook niets, ik moet meteen aan de 90s van vorige eeuw denken met die fans met dat snerpende, hoge geluid.

Ik neem overigens aan dat je Brazos bedoelt? Bv een E-350? Ik weet niet of ik dat wel wil, misschien een tweede handsie en dan t.z.t. een Beema mocht dat in mijn smaak uitkomen.

[ Voor 6% gewijzigd door ABD op 25-11-2014 20:08 ]

[player-x]

92mm vans hoeven helemaal niet veel lawaai te maken, als ze maar rustig genoeg draaien, en dat is in te stellen via de fan controller software.

En is de QC5000 niet een beetje licht voor NewGroups, bv een ASRock H81M-ITX/WiFi, samen met een Celeron G1840 is twee tientjes duurder maar een heel stuk krachtiger, en verbruikt ongeveer het zelfde, en heeft voor de rest vergelijkbare specs.

[Q]

- knip - Q kan niet zo goed lezen. @Ultra, zou een Supermicro bordje niet wat zijn, ongeveer zelfde prijs, met IPMI (dedicated interface)?

[ Voor 164% gewijzigd door Q op 25-11-2014 21:58 ]

[Verwijderd]

ABD schreef op dinsdag 25 november 2014 @ 20:06:
Ik zie vier gaten plus nog 2 waar die heatsink mee vastgezet is, ik moet wel wat kunnen verzinnen. En wellicht is de geleverde heatsink voldoende [..]

Ik neem overigens aan dat je Brazos bedoelt? Bv een E-350?

Nee, ik bedoelde Kabini. Brazos is oud en zou ik echt niet meer nemen. Traag. Kabini quadcore is veel beter. Kabini is een echte SoC en min of meer de tegenhanger van de J1900 Bay Trail SoC van Intel. Maar Intel is 10W en AMD Kabini is 25W TDP. Maar dat laatste zit vooral veel GPU TDP bij; de cores zijn wel aardig zuinig.

Ik heb zelf ASRock AM1H-ITX uit mijn hoofd, met een Athlon 5350. Maar net als bij jou zit ik ook met het probleem dat de bijgeleverde heatsink een fan heeft en dat wil ik dus juist niet. Dus ik heb Arctic Thermal Adhesive (lijm-koelkasta die blijft plakken voor een semi-permanente verbinding) gekocht en hoop daar een custom groot koelblok aan te bevestigen.

Ik was dus in de war, want mijn J1900 bordjes hebben wel allemaal een passieve heatsink. Maar Kabini is met socket en koop je meestal zelf je CPU (Athlon 5350 is de beste). Zoals je zegt heb je aardig wat airflow, maar de bijgeleverde heatsink is echt superklein dus ik maak me toch zorgen dat als je ook de GPU gaat stressen of dat wel goed gaat. Als je ziet hoe Asrock een heatsink gebruikt voor 10W Intel dan mag je wel oppassen.

[Ultra]

Q schreef op dinsdag 25 november 2014 @ 21:56:
- knip - Q kan niet zo goed lezen. @Ultra, zou een Supermicro bordje niet wat zijn, ongeveer zelfde prijs, met IPMI (dedicated interface)?

Ja, ware het niet dat ik eerst wil spelen met een ZFS VM en een Windows VM, en daarvoor in totaal 3 PCIe-kaarten ga doorgeven, die 4 sloten innemen. Dat bord van Intel heeft net dat extra slot.

[nero355]

Nindustries schreef op dinsdag 25 november 2014 @ 14:14:
Je moet juist de AsMedia driver includen in ESXi, heb dat kaartje hier ook liggen.

Dit ligt buiten de scope van dit topic, maar toch een linkje voor borroz.

Verwijderd schreef op dinsdag 25 november 2014 @ 14:24:
ah.. dat heb ik nog nooit gedaan.
ik dacht, prik ze in het mobo en ESXi 'ziet' ze.. maar ik moet dus eerst de drivers installen.
heb gelukkig nog een paar weken om me in te lezen

Puur omdat ik er toevallig een bookmark van heb effe posten : http://www.v-front.de/201...nsupported-sata-ahci.html Succes!

[joopworst]

Verwijderd schreef op dinsdag 18 november 2014 @ 16:39:
Je kunt een RAID controller van Areca niet veilig gebruiken voor ZFS. Je pool kan corrupt raken door reordered writes na een FLUSH request, iets wat RAID controllers zoals Areca doen bij write-back, en je disks kunnen uit de RAID set vallen bij bad sectors en andere timeouts. Dat laatste gebeurt ook met de controller in JBOD mode of individuele disks in passthrough mode. Het is wel mogelijk dat nieuwere firmware (dan versie 1.44) de laatstgenoemde problemen niet heeft; ik heb enkel tot firmware 1.44 getest.

Voor een LSI MegaRaid kaart is er wel een oplossing door alle schijven als RAID0 te configureren
https://calomel.org/zfs_raid_speed_capacity.html
Via de CLI. zoiets zou ook voor een Areca kaart moeten kunnen lijkt me.

[Verwijderd]

nero355 schreef op woensdag 26 november 2014 @ 01:36:
[...]


[...]

Puur omdat ik er toevallig een bookmark van heb effe posten : http://www.v-front.de/201...nsupported-sata-ahci.html Succes!

[Verwijderd]

Bij Areca kun je:

• De schijf in een multi-disk RAID array plaatsen (RAID1, RAID5, RAID6)
• De schijf in een single-disk RAID0 plaatsen
• De schijf in een passthrough mode doorgeven
• De hele controller in 'JBOD' mode plaatsen waardoor alle schijven passthrough worden

Echter, bij alle modi is het gedrag hetzelfde: bij een lange timeout (~20sec) wordt de schijf onzichtbaar en detached. Rebooten werkt in sommige gevallen, maar niet altijd. Soms staat de schijf in de setup utility als 'failed' en moet je de passthrough disk opnieuw aanmaken voordat hij weer zichtbaar kan zijn. Leuk voor remote management (NOT!).

Daarnaast kan Areca je hele ZFS pool corrumperen indien je write-back hebt ingeschakeld. Je kunt dit handmatig wel uitschakelen in de setup utility.

Kortom, Areca is niet geschikt voor een ZFS pool. Je kunt het wel gebruiken om mee te testen, maar voor een echte build wil je toch een echte HBA controller hebben ipv een RAID controller met eigen logic. Alles wat tussen ZFS en de disk in kwestie zit, is een potentieel risico en een RAID controller is daarin het grootste risico voor problemen.

[ABD]

player-x schreef op dinsdag 25 november 2014 @ 20:24:
92mm vans hoeven helemaal niet veel lawaai te maken, als ze maar rustig genoeg draaien, en dat is in te stellen via de fan controller software.

En is de QC5000 niet een beetje licht voor NewGroups, bv een ASRock H81M-ITX/WiFi, samen met een Celeron G1840 is twee tientjes duurder maar een heel stuk krachtiger, en verbruikt ongeveer het zelfde, en heeft voor de rest vergelijkbare specs.

Ik vind het op zich een heel goed idee van je, maar ik vind 25-30W idle veel te veel voor een apparaat wat 24/7 aanstaat.

Verwijderd schreef op dinsdag 25 november 2014 @ 23:06:
[...]

Nee, ik bedoelde Kabini. Brazos is oud en zou ik echt niet meer nemen. Traag. Kabini quadcore is veel beter. Kabini is een echte SoC en min of meer de tegenhanger van de J1900 Bay Trail SoC van Intel. Maar Intel is 10W en AMD Kabini is 25W TDP. Maar dat laatste zit vooral veel GPU TDP bij; de cores zijn wel aardig zuinig.

Ik heb zelf ASRock AM1H-ITX uit mijn hoofd, met een Athlon 5350. Maar net als bij jou zit ik ook met het probleem dat de bijgeleverde heatsink een fan heeft en dat wil ik dus juist niet. Dus ik heb Arctic Thermal Adhesive (lijm-koelkasta die blijft plakken voor een semi-permanente verbinding) gekocht en hoop daar een custom groot koelblok aan te bevestigen.

Ik was dus in de war, want mijn J1900 bordjes hebben wel allemaal een passieve heatsink. Maar Kabini is met socket en koop je meestal zelf je CPU (Athlon 5350 is de beste). Zoals je zegt heb je aardig wat airflow, maar de bijgeleverde heatsink is echt superklein dus ik maak me toch zorgen dat als je ook de GPU gaat stressen of dat wel goed gaat. Als je ziet hoe Asrock een heatsink gebruikt voor 10W Intel dan mag je wel oppassen.

Jij bedoelde de Kabini bordjes met cpu socket, ik met cpu onboard, dat was de verwarring. Ik wil eigenlijk voor dat laatste gaan, omdat ik zoals al gezegd een uiterst energiezuinige oplossing wil. Daar ben ik best bereid snelheid voor in te leveren, maar er is een grens. De machine moet in staat zijn om zonder haperingen 1080p af te spelen terwijl het met SABNZBd aan het uitpakken is, maar dat moet volgens mij kunnen met GPU ondersteuning voor het afspelen van video. Ik vind jouw oplossing net als de G1840 oplossing teveel energie verbruiken. Al is het een stuk beter dan mijn energieslurpende systeem (T1100+HD6950), maar die staat niet altijd aan.

[player-x]

ABD schreef op woensdag 26 november 2014 @ 09:11:
Ik vind het op zich een heel goed idee van je, maar ik vind 25-30W idle veel te veel voor een apparaat wat 24/7 aanstaat.

Ik ben de eerste die zegt, 'kijk ook naar de stroom rekening', maar de A4-5000 is nouwelijks sneller dan de E-350 qua uitpakken (7zip), om 20~30 euro per jaar te besparen, houd er rekening mee dat je NAS dan wat lang met NewGroups bezig kan zijn.

Waar het op neer komt, vraag je zelf af of je geen verkeerde besparing doet.

[FireDrunk]

Ik denk dat de term Race-to-idle ook belangrijk is hier... Een snellere CPU is eerder klaar, en kan eerder terug in standje idle...

[matty___]

Hoe komen jullie toch altijd aan de idle watts? De watts die wordt opgegeven bij een cpu zegt toch niets over zijn idle gebruik

[player-x]

matty___ schreef op woensdag 26 november 2014 @ 11:20:
Hoe komen jullie toch altijd aan de idle watts? De watts die wordt opgegeven bij een cpu zegt toch niets over zijn idle gebruik

De idle Watts die we noemen hebben we van reviews van verschillende test sites, en meestal is idle de belangrijkste waarde voor een server, dus we hebben geleerd om voornamelijk daar naar te kijken.

Uitzonderingen zijn servers die bv VMs draaien, of zo als bij mij, de helft van de tijd aan het (re-)encoden is.

hier vind je het een en ander aan nuttige info: Stroomverbruik van een systeem

[thibautb]

Ik heb een simpel vraagje, je kan toch ook een pentium G-3240 met een h97 bord draaien?

[FireDrunk]

Check even de CPU Support list van de desbetreffende fabrikant. Technisch moet het volgens mij wel kunnen, maar de BIOS moet het wel ondersteunen. Hoewel ik verwacht dat dit 99/100 keer wel goed zit.

[IceTeaGX]

Ugh, VMware begint op mijn zenuwen te werken.
Wil ik gewoon een ZFS server virtualiseren met de nodige controllers in passthrough. Daarop een NFS share door te geven aan VMware als datastore voor de rest van de VM's.

MAAR ESXi werkt niet met softraid oplossingen (LSI megaraid en intel matrix) Voor matrix raid is er naar't schijnt wel een heel onofficiële driver, maar daar heb ik dan ook niet echt zin in
Datastores op USBsticks zijn ze ook allergisch aan. Hoewel er blijkbaar USB sticks zijn die zo gebruikt kunnen worden, de mijne blijkbaar niet.

Ik ga maar even door mijn bak USB stciks graven om eentje te vinden die wel compatibel is.

[ Voor 3% gewijzigd door IceTeaGX op 26-11-2014 15:56 ]

[FireDrunk]

Storage op USB is denk ik een onbegonnen werk... Het ding mag namelijk niet via de standaard Mass Storage driver werken, dan kan je er geen datastore op maken... Misschien met 'custom' drivers wel (zoals sommige USB SD card readers), maar ik zou het er niet op gokken...

Best oplossing is mijns inziens nog altijd een SSD op een lokale AHCI poort... Daar lekker je VM op zetten, en dan in de VM op een passthrough controllers ZFS draaien.

* FireDrunk doet het zelf ook zo...

[IceTeaGX]

Ik dacht het eerst ook zo te doen, maar dan beseft je dat je een perfecte 6 kanaals SATA controller gebruikt voor 1 SSD op aan te sluiten. 2 aansluiten heeft toch geen zin, want ESXi herkent de redundancy niet. Dus als datastore voor andere VM's wil je dat ook niet echt gebruiken.
Anderzijds heb je dan een 60gig SSD (mijn kleinste atm) waarop 4 gig aan data staat en voor de rest niets.
Dat kan ik dan toch ook op een 8GB stick plaatsen, zodat die SSD als L2ARC of slog kan dienen.

Ja ket kan zonder, maar ik ben voorlopig nog te koppig/niet hopeloos genoeg om het zo te doen

[FireDrunk]

Mja, in jouw situatie kan ik dat begrijpen. Ik heb gewoon al mijn VM's lokaal en een Backup VM ingericht die naar ZFS backupped.

Dan kan je gewoon (in theorie) 6 SSD's op je AHCI controller hangen, en je lokale VM's verdelen over de 6 SSD's.

Dan hebben je VM's geen lol van ZFS natuurlijk, dus als je dat graag wil, dan ja, dan zit je inderdaad met zo'n vervelende lokale controller

[IceTeaGX]

Ik kan misschien een Rpi (of nog iets zuiniger) inbouwen/extern voorzien om een micro NFS datastore aan te bieden voor enkel de ZFS van op te starten.

En die 6 SSD's blijven zonder redundancy. Of ik moet al een dedicated RAID controller er voor gaan aankopen, en dan zijn we echt wel zwaar ontspoord. Nog maar te zwijgen van de kost ervan. Ik heb nu 2 SSD's in mijn server zitten, 60GB en 120GB.

[TrsvK]

Ik heb vandaag mijn vervangende schijven van western digital binnnen gekregen nadat ik mijn schijven had ingestuurd omdat deze al na 3 maanden op 150k read cycle counts zaten. (Had WDIDLE vergeten). Nu ik de "nieuwe" schijven heb aangesloten krijg is steeds wanneer ik bestanden ga kopieren naar de pool, de volgende error over een van de schijven in mijn z2 pool.

Nov 28 01:24:47 DelftNas kernel: ahcich15: Timeout on slot 0 port 0
Nov 28 01:24:47 DelftNas kernel: ahcich15: is 00000000 cs 00000000 ss 000003ff rs 000003ff tfd 40 serr 00000000 cmd 0000c917
Nov 28 01:24:47 DelftNas kernel: (ada6:ahcich15:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 40 d0 ac f4 40 12 00 00 00 00 00
Nov 28 01:24:47 DelftNas kernel: (ada6:ahcich15:0:0:0): CAM status: Command timeout
Nov 28 01:24:47 DelftNas kernel: (ada6:ahcich15:0:0:0): Retrying command
Nov 28 01:25:42 DelftNas kernel: ahcich15: AHCI reset: device not ready after 31000ms (tfd = 00000080)
Nov 28 01:25:42 DelftNas kernel: (aprobe0:ahcich15:0:0:0): ATA_IDENTIFY. ACB: ec 00 00 00 00 40 00 00 00 00 00 00
Nov 28 01:25:42 DelftNas kernel: (aprobe0:ahcich15:0:0:0): CAM status: Unconditionally Re-queue Request
Nov 28 01:25:43 DelftNas kernel: (aprobe0:ahcich15:0:0:0): Error 5, Retry was blocked
Nov 28 01:25:43 DelftNas kernel: ada6 at ahcich15 bus 0 scbus15 target 0 lun 0
Nov 28 01:25:43 DelftNas kernel: ada6: <WDC WD40EZRX-00SPEB0 80.00A80> s/n WD-WCC4E0435492 detached
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): CAM status: ATA Status Error
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): Error 5, Retries exhausted
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): NOP. ACB: 00 00 00 00 00 00 00 00 00 00 00 00
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): CAM status: ATA Status Error
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): ATA status: d1 (BSY DRDY SERV ERR), error: 04 (ABRT )
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): RES: d1 04 ff ff ff ff ff ff ff ff ff
Nov 28 01:25:47 DelftNas kernel: (aprobe0:ahcich15:0:0:0): Error 5, Retries exhausted

Hierna is de schijf niet meer bereikbaar en wordt de pool gemarkeerd als degraded. Wanneer ik de NAS opnieuw opstart werkt alles weer en is de schijf weer bereikbaar. De SMART data van de betreffende schijf geeft geen opvallende waarden. Ik heb mijn freenas al geupdate naar de nieuwste versie maar dit heeft niet geholpen.

Heeft iemand een idee waar dit aan kan liggen?

[Verwijderd]

De SMART data van de betreffende schijf geeft geen opvallende waarden.

Geef dan een pastebin linkje zodat we dat ook kunnen checken.

Je hebt voor kabelfouten gecontroleerd?

Heb je de kabels omgewisseld met een schijf waar je geen problemen mee hebt? Welke controller gebruik je?

[FireDrunk]

IceTeaGX schreef op woensdag 26 november 2014 @ 17:28:
Ik kan misschien een Rpi (of nog iets zuiniger) inbouwen/extern voorzien om een micro NFS datastore aan te bieden voor enkel de ZFS van op te starten.

En die 6 SSD's blijven zonder redundancy. Of ik moet al een dedicated RAID controller er voor gaan aankopen, en dan zijn we echt wel zwaar ontspoord. Nog maar te zwijgen van de kost ervan. Ik heb nu 2 SSD's in mijn server zitten, 60GB en 120GB.

Liever een goede backup dan redundancy...