Het grote DIY RAID NAS topic deel 3

[Verwijderd]

Uiteraard staan de schijven is passthrough.

[Verwijderd]

@thelightning87: ik heb zelf met mijn ARC-1220 getest in het verleden (1.42 firmware) en in alle configuraties werden disks uit de array gegooid bij bad sectors:
1) RAID-arrays met elk één disk.
2) Disks in passthrough
3) Hele controller in 'JBOD' mode

Zodra ZFS een bad sector probeert te lezen, knalt de controller de hele disk eruit, poef weg. Je moet dan herstarten voordat de disk weer gevonden wordt. Enorm irritant.

Nog erger is dat soms ook de configuratie verdween. Dus dan moet je weer de Areca setup in en de disk weer in passthrough zetten omdat hij als 'free'/'unused' of whatever stond. Kolere welke knuppel dat bedacht heeft mogen ze de spuit geven.

Verder wel een mooie controller; maar als je geen TLER disks hebt zijn ze niet geschikt voor ZFS. Bovendien geen TRIM ondersteuning enzo, en ook zonde als je een dure controller gebruikt als normale HBA (non-RAID controller).

Wat je het liefste wilt is de chipset AHCI controller van Intel/AMD. Hogere kwaliteit SATA poorten kun je niet krijgen.

[DXaroth]

FireDrunk schreef op maandag 28 juli 2014 @ 09:50:
Balen

Gelukkig is Azerty het met mij eens; ik krijg een nieuwe opgestuurd binnen 3 werkdagen.

altijd fijn om te horen dat ik niet gek begin te worden

[FireDrunk]

Nice! En zo hoort het

[nero355]

Verwijderd schreef op woensdag 30 juli 2014 @ 00:08:
Wat je het liefste wilt is de chipset AHCI controller van Intel/AMD. Hogere kwaliteit SATA poorten kun je niet krijgen.

Wat is daar beter aan dan een losse of onboard LSI controller ?!

Ik weet wel dat er wat lagere latencies en dergelijke zijn, maar IMHO is dat allemaal te verwaarlozen

[Verwijderd]

TRIM ondersteuning, DIPM ondersteuning, ondersteuning voor APM/AAM. Lagere latencies dan IBM M1015 (check gstat). Spindown werkt gewoon via camcontrol commando's. En ik vergeet vast een hoop.

Je hebt liever AHCI dan SAS/SCSI. Helaas zijn AHCI-controllers erg zeldzaam; Marvell en Silicon Image kom je dan uit; en natuurlijk de chipset controller.

[nero355]

Verwijderd schreef op donderdag 31 juli 2014 @ 20:24:
TRIM ondersteuning, DIPM ondersteuning, ondersteuning voor APM/AAM. Lagere latencies dan IBM M1015 (check gstat). Spindown werkt gewoon via camcontrol commando's. En ik vergeet vast een hoop.

Mja... alleen APM/AAM en spindown lijkt me dan interessant, maar daar kan je ook zonder meestal.

Je hebt liever AHCI dan SAS/SCSI. Helaas zijn AHCI-controllers erg zeldzaam; Marvell en Silicon Image kom je dan uit; en natuurlijk de chipset controller.

De LSI controllers met IT firmware / passthrough mode zijn geen AHCI in feite

[FireDrunk]

Nee, dat is SATA over SAS. In de SAS standaard staat expliciet dat SATA ondersteund moet worden (ivm backwards compatibiliteit).

SATA is niet hetzelfde als AHCI. Nou ondersteund het SAS protocol al heeeel lang een vorm van TRIM (namelijk het UNMAP commando), en is dat in veel gevallen wat de driver ook doet. Volgens mij is de LSI driver zo slim om een TRIM commando vanuit het OS om te zetten in een UNMAP commando naar de controller, welke door de firmware weer omgezet zou kunnen worden in TRIM.

Of dat daadwerkelijk zo is, weet ik niet.

Bron: http://www.spinics.net/lists/linux-scsi/msg54080.html

What counts in Linux for "trim" support on a SSD (SATA,
SAS or FC) is correctly processing the SCSI WRITE SAME (16)
with the UNMAP bit set. In the case of a SATA SSD, a SCSI
to ATA Translation Layer (SATL) should map that SCSI WRITE
SAME (16) with the UNMAP bit set to the ATA DATA SET
MANAGEMENT command with the TRIM attribute set.

Many Linux SATA low level drivers use libata which
implements the above mapping. However some SAS HBAs
(e.g. LSI MPT Fusion 3 and 6 Gbps) implement the SATL
in their own HBA firmware.

I tested a LSI SAS 9212-4i4e HBA running its most recent
firmware (9.0 from Feb 26, 2011) with a Intel SSDSA2M080
which does support trim. I used my ddpt utility and the
SCSI WRITE SAME (16) with the UNMAP bit set was rejected
as an "illegal request". With the UNMAP bit clear it
accepted the command. I also checked the SCSI UNMAP
command and it was also rejected.

LSI have some more work to do on their firmware.

(LSI's SAS2008 is een MPT2 controller, welke dus die nieuwe firmware heeft, de oude LSI1068 is nog van de oude MPT standaard, welke dus zeer waarschijnlijk die TRIM / UNMAP functionaliteit niet heeft.)

[ Voor 54% gewijzigd door FireDrunk op 31-07-2014 23:52 ]

[nero355]

Ik zat ook meer te denken aan de 2008/2308/3008 dus dat zit wel goed dan denk ik

[Verwijderd]

nero355 schreef op donderdag 31 juli 2014 @ 23:46:
Mja... alleen APM/AAM en spindown lijkt me dan interessant, maar daar kan je ook zonder meestal.

Als je headparking uit wilt schakelen wil je APM op 254 zetten. Dat lukt niet op een SAS controller onder BSD platform. Onder Linux schijnt het wel te kunnen met de LSI SAS controllers. Dus wellicht een beperking van de FreeBSD-driver voor LSI controllers. Voor WD Greens op LSI SAS controller moet je dan de proprietary utility gebruiken om persistent de headparking op 300 seconden in te stellen.

En DIPM is zeker interessant; dat maakt dat je Intel-controller 0,0 watt gebruikt. Ook als je helemaal niets hebt aangesloten of alleen HDDs. Dit heb ik zelf getest. Bij Marvell maakte DIPM niets uit als er geen apparaten waren aangesloten; die bleef een halve watt slurpen.

[FireDrunk]

nero355 schreef op vrijdag 01 augustus 2014 @ 00:10:
Ik zat ook meer te denken aan de 2008/2308/3008 dus dat zit wel goed dan denk ik

Lees even de laatste regel van de qoute nog een keer

[MTDjassen]

Hoi allemaal!

Ik ben vrij nieuw in de hele NAS wereld. Ik ben recentelijk gaan samenwonen vanuit een studentenwoning dus dan heb je opeens geld, ruimte en een redelijk stabiele internetverbinding om te gaan spelen met dit soort dingen. Ik heb een raspberry pi B+ gekocht die ik wil gebruiken als always on XBMC box, dus die ik direct aansluit op m'n TV. Als dataopslag wil ik dan een NAS bouwen (of kopen, maar ik hou wel van kloten dus liever bouwen).

Ik heb de volgende set-up nu bij elkaar gesprokkeld in de pricewatch:

#	Product	Prijs	Subtotaal
1	ASRock AD2550-ITX	€ 39,98	€ 39,98
2	Seagate Barracuda 7200.14 ST2000DM001, 2TB	€ 68,-	€ 136,-
1	Spire PowerCube SPM210B-300W-PFC	€ 33,-	€ 33,-
1	Crucial CT2C2G3S1339MCEU	€ 36,68	€ 36,68
Bekijk collectie Importeer producten		Totaal	€ 245,66

Als eerste vraag: iemand hierop sterke op/of aanmerkingen? Belangrijk voor mij zijn het stroomverbruik en een redelijk performance, maar (zover mijn kennis reikt) wil ik geen exotische RAID levels gaan gebruiken.

[-The_Mask-]

Die voeding die erbij zit is rommel, daar heb je niks aan.

[GioStyle]

Plus waarom geen 1 schijf van 4TB ipv 2 schijven van 2 TB? Scheelt weer in stroomverbruik en aanschafprijs.

[MTDjassen]

Thanks voor de feedback. Wat betreft de twee schijven dacht ik data redundancy, omdat ik ze ook als backup voor o.a. foto's wil gebruiken? Daarom RAID 1 2x2TB was de gedachte. Klinkt dat ergens naar?

En wat betreft de voeding, definieer 'rommel', onbruikbaar als in levert te weinig vermogen, valt uit elkaar, is inefficient... wat is er 'mis' mee?

[GioStyle]

Als -The_Mask- zegt rommel, denk dan maar aan slechte bouwkwaliteit, slechte efficiëntie en dat soort zaken.

Raid =/= back-up. Raid1 gebruik je puur voor hogere uptime (1 schijf gaat stuk, ander schijf blijft werken). Back-ups maken zou ik sowieso op een extern schijfje doen.

[Paul]

MTDjassen schreef op vrijdag 01 augustus 2014 @ 12:41:
Thanks voor de feedback. Wat betreft de twee schijven dacht ik data redundancy, omdat ik ze ook als backup voor o.a. foto's wil gebruiken? Daarom RAID 1 2x2TB was de gedachte. Klinkt dat ergens naar?

Hoe definieer jij backup? Raid is maar een zeer beperkte vorm van backup (veel mensen vinden het zelfs helemaal geen backup) omdat het vrijwel nergens tegen beschermd, enkel en alleen tegen het uitvallen van één van de twee schijven.

Voor 'echte' backup-doeleinden kun je er beter een 2e schijf naast zetten en daar incrementeel backups naar maken. Welk besturingssysteem wil je gaan gebruiken?

En wat betreft de voeding, definieer 'rommel', onbruikbaar als in levert te weinig vermogen, valt uit elkaar, is inefficient... wat is er 'mis' mee?

Bouwkwaliteit en zo kan ik niet beoordelen, maar waarschijnlijk is het niet heel efficient. Dit bordje gebruikt zo weinig stroom dat je (ook met 2 schijven erbij) niet in het efficiënte bereik van de voeding komt.

Ik zou een PicoPSU nemen

[MTDjassen]

Het mag duidelijk zijn dat ik nog een behoorlijke n00b ben op dit gebied ;-). Mijn gedachte was: als ik al mijn data op schijf 1 ook heb op schijf 2 (wat gebeurt bij RAID1, toch?) heb ik, in het geval van een uitvallende schijf, mijn foto's op in ieder geval een andere schijf nog staan. Zonde is hiervan natuurlijk wel dat al mijn series, films etc ook gemirrored worden, wat onnodig is. Een 'echte backup' is dan wellicht een beter idee. En uiteraard begrijp ik dat het ideaal is om tevens een backup op een andere fysieke locatie te hebben ingeval de hele bende afbrand, ik zit daarom te denken aan een NASshare met een vriend / familielid, maar dat is van latere zorg.

Ik ben van plan FreeNAS te gaan draaien omdat mijn linux ervaring maar zover reikt en dat op mij redelijk gebruiksvriendelijk overkomt.

Bedankt voor de tip over de PSU, ik ga me erin verdiepen

[GioStyle]

Ik gebruik hier gewoon 2x 1TB 2.5" schijfjes voor back-ups. 1 schijf ligt ergens buitenshuis en de andere in huis en om de x aantal weken ruil ik de schijfjes om.

[Mezz0]

Wat ook een leuke backup oplossing is (en project) om je data te backuppen op een nas van een vriend/familie/heele goede kennis. Dit kan via meerdere oplossingen zoals rsync,crashplan,etc.

Heb je meteen een backup en buitenshuis in geval dat alles afbrand of gestolen wordt.

[MTDjassen]

Ja dat wil ik dus liever dan zeulen met XHD's, want ik ken mezelf, dat gebeurt dan één keer in het jaar en dan nooit meer.

[redfoxert]

Ik gebruik Crashplan om backups te maken op een externe server in Frankrijk (zo'n OVH Kimsufi ding) en bij mijn vader 100km verderop. Hij doet hetzelfde met zijn backups. Ook mijn laptops maken backups her en der. Op die manier heb je zowel geografische spreiding en meerdere backups tegelijk

Het mooiste is dat Crashplan voor dit soort doeleinden gewoon gratis is!

[Mezz0]

en ook dat het encrypted is

[MTDjassen]

Inmiddels de case vervangen door een wat duurdere, twijfel nog een beetje tussen:

pricewatch: Chieftec UNI BT-02B-U3

en pricewatch: Thermaltake Element Qi 220W ITX

PicoPSU lijkt me toch teveel gepiel, deze PSU's lijken me qua prestaties al een stuk beter dan die van de Spire.

[Verwijderd]

Waarom teveel gepiel? Juist voor zo'n build is PicoPSU perfect. Bovendien geen lawaai en zuiniger, zelfde prijs als een redelijke voeding. Zoveel 'gepiel' is het toch niet? Duw hem in de ATX-stekker en sluit je netvoeding erop aan. Enig 'gepiel' zou kunnen zijn om een net gat te maken voor de netvoeding-stekker (ronde plug). Er zit een schroef/moer/whatever op dus als je een gat boort waar hij net doorheen kan kun je hem met die moer aan de andere kant klemmen.

[MTDjassen]

Ik vind persoonlijk gaten boren in mijn nieuwe case best wel gepiel, en je bent uiteindelijk wel een eurootje of 40 duurder uit dan met een case + standaard PSU. Ik twijfel nog even rustig verder...

Edit: Voor de toekomstbestendigheid van het geheel, loont het de moeite een andere mobo/soc te kiezen? Ik zit nu gecapped op 4GB mem, terwijl ik overal lees dat stel dat je ZFS wilt gebruiken, 8GB toch wel het absolute minimum is...

[ Voor 36% gewijzigd door MTDjassen op 01-08-2014 14:05 ]

[Verwijderd]

Zoals GioStyle zegt: Als het belangrijke foto's zijn, maak dan ook back-ups op een extrene schijf en dvd/cd en plemp het ook op een usb. Flink back-uppen is wat je wil.Ik spreek uit ervaring en een foto('s) kwijt is een regelrecht drama.Gemakzucht is geen optie.
Ik zou m,n ziel en zaligheid niet laten afhangen van raid 1 ofzo.

My2 cents.

[Verwijderd]

MTDjassen schreef op vrijdag 01 augustus 2014 @ 13:56:
Ik vind persoonlijk gaten boren in mijn nieuwe case best wel gepiel

Een goede ITX-kast heeft sowieso al een plug voor een dergelijke DIN-stekker. En casemodden is inderdaad een tweaker ding, maar even je accuboor pakken, het juiste boortje zoeken en en paar seconden boren hoeft echt niet zoveel werk te zijn.

en je bent uiteindelijk wel een eurootje of 40 duurder uit dan met een case + standaard PSU.

Maar dan vergelijk je appels met peren; PicoPSU kun je beter met een degelijke voeding vergelijken. Dus 40+ euro kast + 55 euro degelijke voeding versus kast + picoPSU. Dan zit je aan ongeveer hetzelfde bedrag. Bovendien geen ventilator meer, geen lomp grote voeding, lager energieverbruik en je scoort Tweakers.net-karmapunten.

Edit: Voor de toekomstbestendigheid van het geheel, loont het de moeite een andere mobo/soc te kiezen? Ik zit nu gecapped op 4GB mem, terwijl ik overal lees dat stel dat je ZFS wilt gebruiken, 8GB toch wel het absolute minimum is...

Even opgezocht en je hebt een ouderwetse Atom gekozen; dat zou ik niet doen. Als je Atom kiest dan een echte SoC dus Bay Trail. Dan zit je aan SuperMicro X10SBA bijvoorbeeld, die heeft 6 SATA en is een leuk bordje. Passief gekoeld en zit al een soort PicoPSU in. Alternatief is pricewatch: ASRock Q1900DC-ITX deze heeft een Bay Trail quadcore en ook een ingebouwde DC-DC voeding ("PicoPSU") dus dan heb je enkel een netvoeding nodig. Hoef je ook geen ronde plug voor te boren omdat de stroomplug gewoon bij de I/O shield zit; waar ook je ethernetkabel in gaat dus.

En 8GiB zou ik zeker doen; gewoon één latje van 8GiB kun je later altijd nog uitbreiden. Voor beide bordjes geldt dat ze zeggen dat 2x4GiB het maximum is. Maar dat is gelul. 8GiB werkt prima.

Gevolg is wel dat je iets meer uitgeeft. Maar je gaat er op vooruit qua snelheid, zuinigheid (geen ATX-voeding meer), uitbreidbaarheid, toekomstbestendigheid en betrouwbaarheid - want zo'n flutvoeding is niks. Koop een leuk setje waar je best wat jaartjes plezier van hebt. Dat is de meerprijs denk ik echt wel waard. Je kunt een twee nieuwe lijstjes maken en die vergelijken.

[DARKviper123]

Verwijderd schreef op vrijdag 01 augustus 2014 @ 14:53:
[...]

Een goede ITX-kast heeft sowieso al een plug voor een dergelijke DIN-stekker. En casemodden is inderdaad een tweaker ding, maar even je accuboor pakken, het juiste boortje zoeken en en paar seconden boren hoeft echt niet zoveel werk te zijn.

[...]

Maar dan vergelijk je appels met peren; PicoPSU kun je beter met een degelijke voeding vergelijken. Dus 40+ euro kast + 55 euro degelijke voeding versus kast + picoPSU. Dan zit je aan ongeveer hetzelfde bedrag. Bovendien geen ventilator meer, geen lomp grote voeding, lager energieverbruik en je scoort Tweakers.net-karmapunten.

Vergeet niet dat een PicoPSU wel een externe powerbrick nodig heeft van minimaal 80W op 12V. Hier zit ook een flink stuk van de complete inefficiëntie in. Deze AC-DC powerbricks hebben geen active-PFC en worden niet getoetst middels een 80Plus certificering. Denk hierbij even aan je laptop adapter, wanneer je laptop aanstaat wordt dit ding ook flink heet, oftewel inefficientie.

Komt nog bij dat bij een onboard voedingssysteem dit een onverwisselbaar deel van de PC wordt, dus bij falen van het voedingsdeel kun je meteen je MoBo incl SOC weggooien. Uiteraard geldt dit niet voor een PicoPSU, die zou je nog kunnen verwisselen. Al zit natuurlijk ook een groot deel van de elektronica in die adapter.

[...]

Even opgezocht en je hebt een ouderwetse Atom gekozen; dat zou ik niet doen. Als je Atom kiest dan een echte SoC dus Bay Trail. Dan zit je aan SuperMicro X10SBA bijvoorbeeld, die heeft 6 SATA en is een leuk bordje. Passief gekoeld en zit al een soort PicoPSU in. Alternatief is pricewatch: ASRock Q1900DC-ITX deze heeft een Bay Trail quadcore en ook een ingebouwde DC-DC voeding ("PicoPSU") dus dan heb je enkel een netvoeding nodig. Hoef je ook geen ronde plug voor te boren omdat de stroomplug gewoon bij de I/O shield zit; waar ook je ethernetkabel in gaat dus.

Zie boven een onboard voeding lijkt me ook nadelen hebben

En 8GiB zou ik zeker doen; gewoon één latje van 8GiB kun je later altijd nog uitbreiden. Voor beide bordjes geldt dat ze zeggen dat 2x4GiB het maximum is. Maar dat is gelul. 8GiB werkt prima.

Voor puur een NAS lijkt 8GB me niet nodig. We doen nu net alsof we hier een soort van uber-server aan het bouwen zijn met functies waar de gemiddelde gebruiker nauwelijks behoefte aan heeft. Toekomstige noodzaak daargelaten.

Gevolg is wel dat je iets meer uitgeeft. Maar je gaat er op vooruit qua snelheid, zuinigheid (geen ATX-voeding meer), uitbreidbaarheid, toekomstbestendigheid en betrouwbaarheid - want zo'n flutvoeding is niks. Koop een leuk setje waar je best wat jaartjes plezier van hebt. Dat is de meerprijs denk ik echt wel waard. Je kunt een twee nieuwe lijstjes maken en die vergelijken.

Een flutvoeding is idd niks. Een 80plus voeding is daarentegen prima! Plus in mijn beredenering is een 80plus voeding welke op 10 - 20% belast wordt beter bestand tegen overbelasting en de gevolgen daarvan dan een pico-psu die al snel op 60 - 80% van zijn kunnen staat te loeien.

Voor degelijkheid zou ik denk ik toch kiezen voor een ITX voeding met 80plus label. Temeer dit meteen netjes in de kast zit weggewerkt. Plus een beetje airflow in je kast is ook niet erg met 2 HDD's en een SOC.

[FireDrunk]

PicoPSU moet je niet met een degelijke voeding vergelijking, PicoPSU is qua materiaal troep... Kwaliteit is helemaal niet zo goed...

Alleen qua verbruik moet je ze vergelijken...

[ Voor 15% gewijzigd door FireDrunk op 01-08-2014 16:15 ]

[Paul]

MTDjassen schreef op vrijdag 01 augustus 2014 @ 12:56:
als ik al mijn data op schijf 1 ook heb op schijf 2 (wat gebeurt bij RAID1, toch?) heb ik, in het geval van een uitvallende schijf, mijn foto's op in ieder geval een andere schijf nog staan.

Yup, bij een uitvallende schijf inderdaad wel Maar dat is dan ook wel het enige

Een corrupt filesystem, een 'oeps' met het delete-commando, het verkeerde bestand bewerkt of een bestand onder de oude naam opgeslagen, daar helpt het allemaal niet tegen

Als je belangrijke dingen ook regelmatig (geautomatiseerd?) naar een ander NAS kopieert dan kan RAID 1 afdoende zijn, absoluut. In dat geval kun je echter ook besluiten dat je data best een dag (of 2) onbereikbaar mag zijn als er een schijf stuk gaat en helemaal geen RAID gebruiken Want je gooit nu om te beginnen al 50% van je ruimte weg aan RAID 1, en dan ga je de data ook nog een keer op een externe locatie opslaan (je backup). Ik kan me indenken dat je dat teveel van het goede vindt

[M3rcury93]

Ik wil een server met ZoL (Ubuntu) gaan draaien met vijf 4TB disks in RaidZ1. Hiervoor had ik de volgende opstelling in gedachte.

#	Product	Prijs	Subtotaal
1	ASRock B85M Pro4	€ 54,99	€ 54,99
1	Intel Celeron G1820 Boxed	€ 29,-	€ 29,-
1	Crucial Ballistix Tactical BLT2C4G3D1608ET3LX0CEU	€ 65,05	€ 65,05
1	Seasonic G-Serie 360Watt	€ 56,95	€ 56,95
1	Cooler Master N300 (KKN1, closed)	€ 30,34	€ 30,34
Bekijk collectie Importeer producten		Totaal	€ 236,33

De server komt thuis te staan en is vooral bedoeld voor data opslag en het downloaden van media bestanden. Nu heb ik nog een paar vragen.

- Zou ik beter af zijn met meer of minder geheugen?
- Is het aan te raden om het OS op een usb stick te draaien? Ik zie voor mij namelijk geen reden SSD te nemen voor bijvoorbeeld L2ARC. Ik kan natuurlijk ook gewoon een oude HDD pakken voor het OS

[Verwijderd]

DARKviper123 schreef op vrijdag 01 augustus 2014 @ 16:04:
Vergeet niet dat een PicoPSU wel een externe powerbrick nodig heeft van minimaal 80W op 12V.

60W is prima hoor, heb je al een behoorlijke marge. Ik heb een 60W adapter getest met spinup met 5 hardeschijven; tot over de 100W piekspanning. Dus 60 of 80W lijkt me prima. Een 150W powerbrick is moeilijk te vinden en een stuk duurder. Zie testresultaten:
Verwijderd in "Het grote DIY RAID NAS topic deel 3"

Hier zit ook een flink stuk van de complete inefficiëntie in. Deze AC-DC powerbricks hebben geen active-PFC en worden niet getoetst middels een 80Plus certificering. Denk hierbij even aan je laptop adapter, wanneer je laptop aanstaat wordt dit ding ook flink heet, oftewel inefficientie.

Toch scheelt het nog 50% aan het stopcontact versus een ATX-voeding, in de meest kale configuratie. Als je voor een ATX-voeding gaat, betekent dit automatisch een minder zuinig systeem.

Testresultaten:
Stroomverbruik Processor+Moederbord+Geheugen
Stroomverbruik SuperMicro X10SBA

Komt nog bij dat bij een onboard voedingssysteem dit een onverwisselbaar deel van de PC wordt, dus bij falen van het voedingsdeel kun je meteen je MoBo incl SOC weggooien.

En je netwerkkaart, en je geluidskaart, en je videokaart, en je USB controller, en je gameport, en je SATA controller, enzovoorts. Om die reden kochten mensen vroeger los dingen. Totale onzin natuurlijk. Wanneer gaat een moederbord nou stuk? En als het gebeurt heb je 2 jaar garantie, en daarbuiten heb je misschien pech en koop je voor 100 euro een nieuwe. Wat is het probleem?

Voor puur een NAS lijkt 8GB me niet nodig. We doen nu net alsof we hier een soort van uber-server aan het bouwen zijn met functies waar de gemiddelde gebruiker nauwelijks behoefte aan heeft.

Out of the box ben je met 4GiB best beperkt in performance en mogelijkheden. Zo heb je geen ZFS prefetching onder BSD platform met 4GiB. Ook ben je erg beperkt in ARC cache, kun je weinig metadata cachen, en is iets als een VM draaien in combinatie met ZFS vrijwel uitgesloten. Mocht je ooit later willen uitbreiden, heb je ook weinig aan je 4GiB stick omdat je 8GiB modules wilt hebben. Dus beter om met één 8GiB module te beginen en uit te breiden naar 16GiB.

Ga je echt voor budget dan kun je met 2GiB volstaan. 256MB zelfs in de meest extreme gevallen; maar beneden de 2GiB kun je bijvoorbeeld ZFSguru niet eens booten. Die draait het operating system in RAM.

FireDrunk schreef op vrijdag 01 augustus 2014 @ 16:15:
PicoPSU moet je niet met een degelijke voeding vergelijking, PicoPSU is qua materiaal troep... Kwaliteit is helemaal niet zo goed...

Is het ook de mening van de kenners dat een PicoPSU 'troep' is? Ik zou zeggen hoe minder componenten, des te minder kan er stuk gaan. Ik heb van al mijn 14 PicoPSUs nog nooit eentje gehad die het begaf. Alleen maar plezier mee gehad. Bovendien bouw ik nooit meer een computer met bewegende onderdelen zoals ventilators, hardeschijven uitgezonderd maar ook die wil ik zo gauw het kan de bons geven.

[Verwijderd]

Voor de overzichtelijkheid in een nieuw bericht:

Paul schreef op vrijdag 01 augustus 2014 @ 17:04:
Een corrupt filesystem, een 'oeps' met het delete-commando, het verkeerde bestand bewerkt of een bestand onder de oude naam opgeslagen, daar helpt het allemaal niet tegen

ZFS beschermt daar wel tegen, omdat het meer is dan alleen 'RAID'. Met snapshots heb je geschiedenis zodat je tegen ongelukjes beschermt bent zoals de verkeerde directory verwijderen. Corrupt filesystem is ook een vrijwel onmogelijke situatie voor ZFS tenzij je hardware RAID gebruikt in combinatie met ZFS. Corrupte bestanden biedt ZFS sowieso bescherming tegen.

Vergelijk dat met een traditionele RAID setup + backup. Daarbij kan corruptie ongemerkt naar de backup vloeien omdat er geen enkele bescherming is tegen corruptie. Zodoende kan het voorkomen dat je met een dergelijk 'veilige' setup alsnog corruptie hebt in je trouwfoto's/whatever.

Veilige opslag begint toch echt met een 3e generatie filesystem.

Wil je daarnaast nog bescherming tegen kometen en de nukes van Putin, dan is een off-site/online backup een nuttige aanvulling. Maar als je al begint met een onveilig filesystem wat corruptie geeneens kan detecteren, laat staan corrigeren, dan heb je mijns inziens geen veilig opslagsysteem.

M3rcury93 schreef op vrijdag 01 augustus 2014 @ 17:13:
Ik wil een server met ZoL (Ubuntu) gaan draaien met vijf 4TB disks in RaidZ1. Hiervoor had ik de volgende opstelling in gedachte.

- Zou ik beter af zijn met meer of minder geheugen?
- Is het aan te raden om het OS op een usb stick te draaien? Ik zie voor mij namelijk geen reden SSD te nemen voor bijvoorbeeld L2ARC. Ik kan natuurlijk ook gewoon een oude HDD pakken voor het OS

2x 4GiB zou ik nooit doen. Je beperkt daarmee je uitbreidingsmogelijkheden. Kies dan één reepje van 8GiB. Kun je later nog uitbreiden naar 16GiB wil je zaken als virtual machines doen, of lekker veel metadata cachen zodat je razendsnel door de directories kunt zappen en kunt zoeken. Heb je ook geen L2ARC meer nodig.

USB-stick zou ik enkel overwegen als je een embedded OS gebruikt, zoals FreeNAS aanbiedt. Plain Ubuntu met allerlei kleine writes is een USB stick niet geschikt voor; zeker niet de slechte USB sticks die ultra ultra ULTRA traag zijn met kleine writes. Bovendien kunnen die al na een maand defect raken.

Je kunt natuurlijk gewoon je HDDs zo partitioneren dat je een systeem/boot partitie hebt en de 2e partitie voor ZFS gebruikt. Dat bijt elkaar niet/nauwelijks. Oude HDD gebruiken enkel voor systeem lijkt me zonde; weer extra verbruik en vooral oudere HDDs <1TB kunnen erg onzuinig zijn. Denk aan 16 euro (8W) extra kosten per jaar.

[M3rcury93]

Verwijderd schreef op vrijdag 01 augustus 2014 @ 23:07:
Je kunt natuurlijk gewoon je HDDs zo partitioneren dat je een systeem/boot partitie hebt en de 2e partitie voor ZFS gebruikt.

Waarom moeilijk doen als het natuurlijk ook gewoon makkelijk kan?7( Thanks CiPHER.

[MTDjassen]

Na wat gelezen te hebben in het ZFS topic van CiPHER ben ik wel van plan om ZFS te gaan draaien icm FreeNAS (je hebt me overtuigd).

Nu is alleen de vraag welke schijven ik ga aanschaffen. Ik heb nu in mijn set-up 2x2T Barracuda, maar voor RaidZ1 heb ik 3 disks nodig. Loont het te moeite om voor die RaidZ1 te gaan ipv ZFS+Raid1? Is wel wéér een extra investering...

[Paul]

Ook op een mirror-configuratie kun je ZFS gebruiken RAIDZ1(/2/3) is geen vereiste voor ZFS, het is een manier om redundantie in je data te bereiken zodat er 'iets' is om corruptie mee te herstellen, net zoals een mirror dat is. Je kunt dus gewoon een mirror maken

Behalve een investering is het ook een verdubbeling van de nuttige ruimte Een mirror van 2x2 TB levert je ~2 TB aan nuttige ruimte op. Een RAID Z1 van 3x2TB levert je ~4 TB aan nuttige ruimte op.

[MTDjassen]

Mja, zoiets dacht ik al, thanks. Compliceert de boel wel weer een beetje, moet nu een case met intern 3x3,5" bays en mijn mobo heeft slechts 2xsata600 en voor de rest sata300. Gaat die sata300 in de praktijk mijn performance omlaag trekken?

[FireDrunk]

Nee, schijven trekken de SATA300 link nog niet eens vol.

Maar je kan toch gewoon een mirror maken van 2*2TB? Niemand die dat raar vind hoor

[MTDjassen]

Ja maar mirror is wel echt zonde van m'n schijfruimte imho. Gaat voor het grootste deel series/movies/muziek op waar het me werkelijk geen klap interesseert wat ermee gebeurt als een schijf ermee ophoudt, als ik dan met een relatief kleine investering zowel mijn gebruiksruimte kan verdubbelen en nog steeds dezelfde redundancy behoudt lijkt me dat een betere optie.

[Paul]

Nee hoor, 300 MB/sec is meer dan genoeg voor een harde schijf. Schijven halen ~100 MB/sec sustained, die 200 MB die je dan over hebt kan de schijf gebruiken om zijn 32 of 64 MB aan cache over te dumpen maar dat is milliseconde-werk

Ik zou altijd* Paul een kast nemen waar minimaal evenveel schijven in kunnen als je onboard SATA-poorten hebt, dan kun je in de toekomst uitbreiden. Het prijsverschil tussen een kast met 3 en eentje met 6 bays is minimaal

* Paul Tenzij je er geen ruimte voor hebt in huis

Edit: Als je data je toch niet boeit kun je misschien beter die 2x2 TB verkopen en er 1x 4 voor terugkopen? is een stuk zuiniger Of je haalt van V&A een 2 TB schijf, scheelt weer 33% op de extra investering.

[ Voor 17% gewijzigd door Paul op 04-08-2014 10:50 ]

[FireDrunk]

Wat je misschien ook kan doen, is de schijven partitioneren, 1 partitie van 200GB voor je belangrijke shit, en een partitie van 1.6GB voor je media/series.

De twee eerste partities zet je in Mirror, en de twee tweede partities zet je in stripe voor ruimte (of gebruik je los, dat is iets veiliger).

[MTDjassen]

Paul schreef op maandag 04 augustus 2014 @ 10:47:

Edit: Als je data je toch niet boeit kun je misschien beter die 2x2 TB verkopen en er 1x 4 voor terugkopen? is een stuk zuiniger Of je haalt van V&A een 2 TB schijf, scheelt weer 33% op de extra investering.

Niet al mijn data boeit me. Of in ieder geval niet in zulke mate dat ik 2TB compleet wil mirroren. 200G formatteren is op zich een optie, of toch voor 3 schijven in RAIDZ1 gaan, met de volgende setup:

#	Product	Prijs	Subtotaal
1	ASRock Q1900DC-ITX	€ 96,11	€ 96,11
3	Seagate Barracuda 7200.14 ST2000DM001, 2TB	€ 68,-	€ 204,-
1	MS-Tech CA-0210 Rev. B	€ 30,49	€ 30,49
1	Crucial CT102464BF160B	€ 63,95	€ 63,95
Bekijk collectie Importeer producten		Totaal	€ 394,55

Wel een lelijk kassie (en te groot naar mijn smaak), maar het moet dan maar.

[FireDrunk]

Andere schijven nemen, die 7200.14's zijn ruk.

[MTDjassen]

Ik heb van CiPHER geleerd dat dat niet uitmaakt met ZFS .

Edit: WD Green significant beter dan? Wellicht wel lief met always-on systeempje.

[ Voor 42% gewijzigd door MTDjassen op 04-08-2014 11:04 ]

[Paul]

Let wel dat die 2 extra SATA-poorten door een ASMedia-chipje komen. Ik lees op Google gemengde resultaten, vooral mensen die het op FreeBSD wel werkend hebben en mensen die het op FreeNAS niet werkend hebben

[MTDjassen]

De Sata600's bedoel je dan. Waar je lees je dit, kan het zelf niet direct vinden. Zou wel zuur zijn...

Edit: Al die berichten zijn uit 2011/2012. Mag er toch vanuit gaan dat er sinds die tijd wel ontwikkeling zit in de ondersteuning van relatief mainstream SATA controllers?

[ Voor 66% gewijzigd door MTDjassen op 04-08-2014 11:14 ]

[Paul]

o.a. https://forums.freebsd.org/viewtopic.php?&t=24929 en http://forums.freenas.org...-controller-problem.6117/, al is er bij die laatste ook weer iemand bij wie het wel werkt

[MTDjassen]

En dan nog een klein vraagje. Stel dat ik mijn NAS tevens wil gebruiken als media center in de woonkamer met XBMC, dan is FreeNAS niet de way to go denk ik? Wat zijn mijn opties in zo'n geval of gaat dat überhaubt lastig worden. FreeBSD moet dan lukken, maar dat vereist weer veel meer kennis denk ik om daar een NAS systeem op te runnen. Iemand tips? Of gewoon niet proberen en een raspberry aan m'n TV hangen voor de doorgifte?

[Verwijderd]

MTDjassen schreef op maandag 04 augustus 2014 @ 10:36:
Na wat gelezen te hebben in het ZFS topic van CiPHER ben ik wel van plan om ZFS te gaan draaien icm FreeNAS (je hebt me overtuigd).

Jeeeeej, weer een schaap uit de put gered!

MTDjassen schreef op maandag 04 augustus 2014 @ 10:59:
Ik heb van CiPHER geleerd dat dat niet uitmaakt met ZFS .

Seagate 7200.14 werkt natuurlijk prima met ZFS, maar de schijf zelf is best ... ruk. Ze zijn snel dat wel, maar vooral erg luidrichtig en ook helemaal niet zuinig. Deze schijven doen vrij agressief aan BGMS - Background Media Scanning. Dat is een techniek om weak sectors op te sporen voordat het bad sectors worden. Dit gebeurt door regelmatig de hele schijf uit te lezen als hij idle is. Dit doet de schijf zelf, en kun je op geen enkele manier uitschakelen ook niet via HPA commando's. Het vervelende is dat dit allerlei 'tikjes' geeft, heel licht, maar voor mij voldoende om er helemaal gek van te worden. Spindown gebruik ik om daar vanaf te komen, maar ik heb ze nu als standby NAS in gebruik die dus maar zelden online komt. Voor mijn always-on NAS gebruik ik de nieuwste WD Greens (WD40EZRX 4TB). Dat zijn de beste schijven die ik ooit in bezit heb gehad. Enorm tevreden mee; stil, zuinig, koel en snel zat zeker voor 5400rpm. Volgens BackBlaze ook betrouwbaar qua failure rates, maar op individueel niveau kun je daar niet veel over zeggen. Jij kan net pech hebben met de Greens; zo gaan die dingen.

MTDjassen schreef op maandag 04 augustus 2014 @ 11:36:
En dan nog een klein vraagje. Stel dat ik mijn NAS tevens wil gebruiken als media center in de woonkamer met XBMC, dan is FreeNAS niet de way to go denk ik? Wat zijn mijn opties in zo'n geval of gaat dat überhaubt lastig worden. FreeBSD moet dan lukken, maar dat vereist weer veel meer kennis denk ik om daar een NAS systeem op te runnen. Iemand tips?

Ik zou sowieso voor een ZFS appliance gaan. Zelf FreeBSD gaan draaien is best gekkenwerk als er drie projecten zijn die dit veel beter kunnen en veel laagdrempeliger werken: FreeNAS, NAS4Free en ZFSguru. Die zijn alledrie gebaseerd op FreeBSD en dus ook goede kwaliteit ZFS implementatie. Maar dan is je leercurve wel een heel stuk relaxter dan dat je gelijk UNIX moet gaan leren.... dat is best een grote stap en niet newbie-proof.

Paul schreef op maandag 04 augustus 2014 @ 11:06:
Let wel dat die 2 extra SATA-poorten door een ASMedia-chipje komen. Ik lees op Google gemengde resultaten, vooral mensen die het op FreeBSD wel werkend hebben en mensen die het op FreeNAS niet werkend hebben

ASMedia werkt prima hoor, onder non-Windows OS in elk geval. Gebruik je de AHCI-driver van FreeBSD en dat betekent dat je alle glorie hebt (APM/AAM/TRIM/Spindown). Het kan wel zijn dat oudere FreeNAS-releases de device-ID nog niet hadden en dus niet herkent wordt als AHCI controller die door de AHCI-driver kan worden gebruikt. Maar verder ben ik me niet op de hoogte van problemen met ASMedia onder BSD. Onder Windows is het andere koek omdat daar de ASMedia-drivers gebruikt worden, en die zijn behoorlijk ruk en ondersteunen bijvoorbeeld ook geen TRIM wat voor SSDs een groot gemis is.

[MTDjassen]

Verwijderd schreef op maandag 04 augustus 2014 @ 11:54:

Ik zou sowieso voor een ZFS appliance gaan. Zelf FreeBSD gaan draaien is best gekkenwerk als er drie projecten zijn die dit veel beter kunnen en veel laagdrempeliger werken: FreeNAS, NAS4Free en ZFSguru. Die zijn alledrie gebaseerd op FreeBSD en dus ook goede kwaliteit ZFS implementatie. Maar dan is je leercurve wel een heel stuk relaxter dan dat je gelijk UNIX moet gaan leren.... dat is best een grote stap en niet newbie-proof.

Ja logisch, natuurlijk. Ik heb wel wat UNIX ervaring, dwz een Linux Mint gedraaid en een sudo apt wil nog wel lukken, maar veel verder kom ik niet in een terminal. Andere kant is dat het zonde is voor die hardware die toch in de huiskamer gaat staan om niet een HDMI kabel naar m'n TV te trekken en XBMC te kunnen draaien, maar dat lijkt dus lastig verenigbaar met één van deze 3 dedicated NAS systemen. Ik dacht wellicht is er een truc om dat mogelijk te maken, maar dat lijkt dus niet zo te zijn. If so, then not. Dan hang ik mijn raspberry pi wel aan de TV en draait die XBMC, dat kan natuurlijk ook.

Ik ga denk voor 3x pricewatch: WD Green WD20EZRX dan, FreeNAS en RAIDZ1.

Edit: Laatste puntje. Aanschaf van de adapter voor Q1900DC-ITX, waar let ik op? Ik heb hierop geselecteerd http://tweakers.net/categ...2bgtUUWOku5q_0jT4M1bNR6xc. Is het dan om het even? Vanwege de formfactor denk ik aan pricewatch: Huntkey 65W Slim. Of zijn er nog belangrijke zaken om op te letten?

[ Voor 17% gewijzigd door MTDjassen op 04-08-2014 12:37 ]

[Verwijderd]

Verwijderd schreef op vrijdag 01 augustus 2014 @ 23:07:
Voor de overzichtelijkheid in een nieuw bericht:

[...]

ZFS beschermt daar wel tegen, omdat het meer is dan alleen 'RAID'. Met snapshots heb je geschiedenis zodat je tegen ongelukjes beschermt bent zoals de verkeerde directory verwijderen. Corrupt filesystem is ook een vrijwel onmogelijke situatie voor ZFS tenzij je hardware RAID gebruikt in combinatie met ZFS. Corrupte bestanden biedt ZFS sowieso bescherming tegen.


[...]

Je 'vergeet' alleen even te vermelden dat, tenzij je ECC geheugen gebruikt, een geheugen defect uiteindelijk je hele array onleesbaar zal maken. En ja de kans op defect geheugen is relatief klein. Maar als het ongedetecteerd blijft is het wel catastrofaal.

Een ander punt is hoeveel ruimte je reserveert voor oude versies van bestanden. Een encryptie virus op je PC zal alle bestanden op je gemounte NAS volumes encrypten. Je moet dan wel voldoende ruimte hebben om alle oude bestanden te behouden (oftewel minimaal 50% vrije ruimte voor het virus toeslaat)

Een NAS is geen backup! Je kan hem wel onderdeel maken van je backup strategie bijvoorbeeld:
PC->Backup naar NAS(Target volume niet 'mounten')->backup naar offsite (bijv. crashplan/Amazon Glacier)


Je hebt nu een dubbele backup van je PC, op twee media, waarvan één off-site. Echter Van de data die je direct opslaat op je NAS en niet op je PC heb je alleen een off-site backup. Dus daarnaast nog even die data naar een Externe Harddisk backupen oid.

(Overigens zijn OneDrive en Google Drive geen backups, alle ellende die op je PC gebeurt zal immers via de sync functionaliteit ook online gebeuren en op al je andere machines als je niet oppast en ermee online gaat.

[FireDrunk]

Verwijderd schreef op maandag 04 augustus 2014 @ 12:53:
[...]

Je 'vergeet' alleen even te vermelden dat, tenzij je ECC geheugen gebruikt, een geheugen defect uiteindelijk je hele array onleesbaar zal maken. En ja de kans op defect geheugen is relatief klein. Maar als het ongedetecteerd blijft is het wel catastrofaal.
*knip*

Dat is allang ontkracht door 1 van de main Dev's van ZFS. ECC helpt, het is niet verplicht.
De alarmbellen van ZFS zullen alleen wat sneller afgaan omdat het corruptie op disk ziet die waarschijnlijk veroorzaakt word door je geheugen, maar de geoefende Systeembeheerder is daar snel genoeg achter.

[Verwijderd]

Verwijderd schreef op maandag 04 augustus 2014 @ 12:53:
Je 'vergeet' alleen even te vermelden dat, tenzij je ECC geheugen gebruikt, een geheugen defect uiteindelijk je hele array onleesbaar zal maken.

Oh de angst voor non-ECC blijft onverminderd hoog! Het helpt ook niet als rottweilers op het FreeNAS forum allerlei dingen gaan zeggen waar mensen in gaan geloven....

Ik heb zelf testjes gedaan met brak geheugen wat vele duizenden fouten per seconden genereert. Dat veroorzaakte flink wat corruptie op de ZFS pool bij een scrub, iets wat keihard weer gecorrigeerd werd na een volgende scrub met goed geheugen.

Als brak geheugen wat heel veel fouten genereert de pool niet plat krijgen, hoef je ook niet zo heel bang te zijn dat non-ECC RAM zomaar je pool corrupt maakt. Dat lijkt mij echt een extreem kleine kans. De kans dat je server een nuke van Putin op zijn dak krijgt, is wellicht nog groter.

Het gevaar is wel dat één of meer bestanden defect raken. Dit komt omdat er corruptie kan plaatsvinden bij het aanmaken van de checksum. Als de checksum eenmaal fout is, dan worden alle datablocks die wellicht wel corruptievrij zijn, ook afgekeurd. Maar dit kun je prima detecteren via zpool status -v - je ziet precies welke bestanden het om gaat. Bovendien kun je ze ook niet lezen, dus je corruptie kan niet naar backups vloeien. En je komt er snel genoeg achter dat er iets mis is.

Vaak is het zo dat RAM corruptie snel genoeg wordt opgemerkt als je ZFS gebruikt, juist door de checksum fouten. Memtest draaien en geheugen omwisselen verhelpt het probleem; vrijwel altijd zonder permanente corruptie.

Het verhaal dat je bij ZFS persé ECC geheugen moet gebruiken, is denk ik gewoon onzin. Het is een extra vorm van zekerheid, die je juist als je geen ZFS gebruikt extra hard nodig hebt. Gebruik je ZFS dan is de noodzaak voor ECC geheugen juist veel minder. Bedenk ook dat ECC op je server alleen niet genoeg is - ook je clients moeten dan ECC hebben. ZFS kan nog zoveel bescherming bieden, als je Windows desktop corrupte data aanlevert dan kan ZFS natuurlijk ook niets meer beginnen....

Een ander punt is hoeveel ruimte je reserveert voor oude versies van bestanden. Een encryptie virus op je PC zal alle bestanden op je gemounte NAS volumes encrypten. Je moet dan wel voldoende ruimte hebben om alle oude bestanden te behouden (oftewel minimaal 50% vrije ruimte voor het virus toeslaat)

Dat zal een lange tijd duren dan als je alle data via het netwerk aan het herschrijven bent. Daar kom je snel genoeg achter dan dat er iets vreemds gebeurt. En met één commando heb je je snapshot ook weer herstelt. Oftewel: ZFS saves the day!

ZFS en Backups bieden veel overlap aan bescherming. ZFS alleen biedt niet de volledige bescherming van een backup, maar andersom evengoed: een backup alleen biedt niet volledige bescherming die ZFS wel biedt. Een combinatie van beide is natuurlijk het allerbeste, maar niet iedereen kan een 1:1 backup veroorloven, zeker als het om minder belangrijke data gaat. Het feit dat je zeker weet dat je geen ongemerkte corruptie krijgt, is vaak al precies wat je wilt.

[Ultra]

FireDrunk schreef op maandag 04 augustus 2014 @ 13:35:
[...]

Dat is allang ontkracht door 1 van de main Dev's van ZFS. ECC helpt, het is niet verplicht.
De alarmbellen van ZFS zullen alleen wat sneller afgaan omdat het corruptie op disk ziet die waarschijnlijk veroorzaakt word door je geheugen, maar de geoefende Systeembeheerder is daar snel genoeg achter.

Bron?

Het is niet verplicht inderdaad, maar dat ZFS alles wel voor je oplost is bullshit volgens een Nexenta medewerker:

quote: http://nex7.blogspot.nl/2...ecc-ram-great-debate.html

If you choose to use non-ECC RAM, you open yourself up to a new vector for data corruption/loss/downtime/errors/etc, one that could (rarely) even cause you to lose your entire filesystem, and one ZFS does not (cannot) resolve for you. Indeed, one it likely can't even see at all. If you choose to employ non-ECC RAM, or are forced to do so because of circumstance or environmental constraint, that's potentially understandable (and even acceptable) - but do not then attempt to validate or explain away that choice with pseudoscience or downplaying the risk you've added. You are using an inferior solution with an extra vector for data corruption/loss that ECC RAM solutions simply do not have. It is that simple.

Maar het kan nog erger :

quote: https://groups.google.com.../qguq6LCf1QQ/MM_p2v9feQ4J

[...] people who really care about their computation, for the longest time, didn't use x86 processors. They used IBM mainframe processors, SPARC chips, etc. Why? Because, at least 10 years ago, the ALU's in x86 chips had *zero* protection. So while there may have been memory protection - the results of the ALU were completely unprotected. PowerRISC, SPARC, PA-RISC, etc. at least all had parity protected ALU's. Parity can't correct the calculation, but it can detect a single bit fault.

If you really want to protect your data end-to-end, you likely, still need to buy a better class of machine. It might now be included in x86 class processors, but I can't find anything that says the ALU's are protected.

[Verwijderd]

Maar niet iedereen draait een kerncentrale of een apollo-ruimteveer of iets anders wat 100% en echt 100% zeker weten moet werken.

Errorcorrectie is één ding, errordetectie heeft niemand het over. En juist dat is denk ik het belangrijkste voor de doorsnee thuisgebruiker. Als in een vreemd geval file X dood is en je kunt dat zien, is dat al een grote winst.

Bovendien, we kunnen over extreem kleine risico's praten, mensen hier komen van NTFS... komop.... je hoeft toch niet gelijk naar het ALLERbeste te gaan en duizenden euro's uitgeven aan exotische hardware, van NTFS naar ZFS is al een MEGA-stap in termen van databescherming.

[Ultra]

Prima, maar zeggen dat er geen risico is, of dat ZFS het wel opvangt, is onzin. Als iets je niet belangrijk lijkt (voor een thuisgebruiker), of het risico is heel klein, wil niet zeggen dat je mag doen alsof het niet bestaat/onmogelijk is.

[ Voor 7% gewijzigd door Ultra op 04-08-2014 14:48 ]

[FireDrunk]

Ultra schreef op maandag 04 augustus 2014 @ 14:27:
[...]

Bron?

Allan Jude @ BSDnow (weet even niet welke aflevering), Allan Jude is zelf een BSD programmeur, en heeft bijvoorbeeld de ZFS on Root installatie gemaakt in de huidige FreeBSD 10 installatie.
Hij gaat altijd naar de BSDcan/con meetings, daar heeft hij het een keer aan een ZFS dev gevraagd.

En nogmaals, ik zeg niet dat het nutteloos is, het is zelfs heel heel heel erg nuttig, alleen is niet verplicht voor een goede werking van ZFS...

En de manier waarop het je hele pool kapot kan maken is als er een bitflip gebeurt in ZFS' programma geheugen en er verkeerde instructies weggeschreven worden. De kans daarop is klein, en als het voorkomt, kan je zeer waarschijnlijk nog met ZDB (op een werkend systeem) de laatste transacties terugdraaien waarmee je de verrotting gewoon weer ongedaan kan maken... Dat is nou juist de kracht van ZFS.

Tuurlijk kan het kapot, het kan zelfs ontzettend kapot gaan, maar als je zelf goed oplet, en je setup simpel houdt, is er altijd nog een hoop te repareren, zelfs met corrupt geheugen.

Is ECC daarom overbodig, nee zeker niet, maar zie het niet als de heilige graal... Het is (net als zoveel andere systemen) een extra laag bescherming.

Als ik moest kiezen tussen 2 servers zonder ECC of 1 server met, zou ik blindelings voor 2 servers zonder ECC gaan...

Nog een extra bron: http://forums.freenas.org...on-ecc-ram-and-zfs.15449/
Ik ben het op zich met hem eens, ware het niet dat hij punt 5 een beetje overtrekt... ZFS' on-disk filesysteem word ook transactioneel (of atomair) weggeschreven. En ook die changes zijn terug te draaien met ZDB (zij het niet, dat dat wat ingewikkeld is ). Dus zelfs ZFS metadata corruptie is terug te draaien... Je hele pool verliezen is dus niet zo simpel als hij het doet voorkomen.

Feit blijft: Als je geen geneuzel wil, koop je ECC, wil je wat goedkoper uitzijn met een fractioneel hoger risico, dan kies je voor non-ECC...

[ Voor 71% gewijzigd door FireDrunk op 04-08-2014 15:06 ]

[Verwijderd]

Ultra schreef op maandag 04 augustus 2014 @ 14:48:
Prima, maar zeggen dat er geen risico is

Wie zegt dat?

of dat ZFS het wel opvangt, is onzin.

ZFS heeft in mijn geval alle checksum errors gecorrigeerd zonder permanente corruptie. Wel tijdelijke corruptie, maar door de redundantie met een latere scrub gewoon weer gecorrigeerd. Dat betekent dat ZFS ook tegen RAM bitflips een vorm van bescherming biedt. Maar niemand claimt dat dat 100% is.

Het belangrijkste risico is dat de checksums verkeerd worden aangemaakt; daarmee is die file direct corrupt, onafhankelijk van de data op de disks en welke redundantie werd gebruikt.

Maar doen alsof een RAM bitflip gelijk je ZFS pool om zeep helpt is pure onzin. Het is theoretisch vast mogelijk dat een combinatie van bitflips op het verkeerde moment/plek inderdaad ernstige gevolgen kan hebben, maar ZFS kan prima tegen een stootje. Als je een thuisgebruiker bent, kun je prima zonder ECC.

Dat gezegd hebbende, vind ik dat iedere computer over ECC RAM dient te beschikken. Het is technisch onjuist om voor een euro die bescherming weg te laten. Maar het is een politiek-economisch-strategische keuze van de grote bedrijven zoals Intel om flink geld te vragen voor ECC, om aan productsegregatie te doen, zodat zakelijke klanten flink meer moeten betalen. Ze willen niet dat klanten met poen goedkoop consumentenspul kopen. Helaas, zo zit de wereld van het grote geld in elkaar. Dus je moet afwegingen gaan maken.

[MTDjassen]

Voor de geïnteresseerden die het wellicht als inspiratie willen gebruiken. Ik heb zojuist deze set-up als final besteld:

#	Product	Prijs	Subtotaal
1	ASRock Q1900DC-ITX	€ 96,36	€ 96,36
3	WD Green WD20EZRX	€ 69,88	€ 209,64
1	MS-Tech CA-0210 Rev. B	€ 30,49	€ 30,49
1	Crucial CT102464BF160B	€ 63,95	€ 63,95
1	Seasonic Power Adapter 80 Watt (12V)	€ 30,50	€ 30,50
Bekijk collectie Importeer producten		Totaal	€ 430,94

[Verwijderd]

Hele mooie setup.

[Q]

Verwijderd schreef op maandag 04 augustus 2014 @ 15:07:
ECC

Dat ECC duurder is, is geen conspiracy theorie van bedrijven. Je hebt meer bitjes nodig om die extra parity info in op te slaan, dus voor de zelfde capaciteit heeft is meer fysiek geheugen nodig. Het prijsverschil is tientjes werk.

Vergeet niet, ZFS is nooit gemaakt voor thuisgebruik, maar voor enterprise omgevingen. ZFS is ontwikkeld met als focus behoud van dataintegriteit. Performance kwam op de 2e plaats, dat is nooit het primaire doel geweest. Dataintegriteit is de heilige graal van ZFS.

Ik vind het zelf onzinnig dat mensen wel ZFS gaan gebruiken en blijkbaar zo paranoide zijn dat ze ZFS checksums willen gebruiken, maar dan geen ECC geheugen gaan gebruiken.

Wat heeft het voor zin om checkums los te laten op garbage? Het geeft een vals gevoel van veiligheid.

Natuurlijk is het zo dat dan desktops het meeste risico vormen omdat zij geen ECC draaien, maar het zou wel erg stom zijn als een file OK is op je desktop en dan corrupt terecht komt op je NAS storage omdat notabene je NAS rot geheugen heeft.

Dit is waarom het zo gestoord is om ZFS zonder ECC geheugen te draaien:

1. Data wordt verstuurd naar de ZFS NAS
2. Data komt op een storage device terecht dat niet wordt gechecksummed (RAM) of integriteitsbescherming heeft (geen ECC).
3. Data wordt geschreven naar storage met checksums/integriteit bescherming.

Het feit dat je nu met ZFS draait maakt je data in dit scenario niet beter beschermd dan andere file systems. ZFS heeft je alleen wat te bieden als je ECC gebruikt, anders is het poppenkast. Want garbage-in is garbage out.

Als je vindt dat ECC niet nodig is voor een thuis nas, dan is ZFS ook niet nodig voor een thuis NAS, is mijn stelling.

Als ik moest kiezen tussen 2 servers zonder ECC of 1 server met, zou ik blindelings voor 2 servers zonder ECC gaan...

Ik zou blindelings voor een enkele server met ECC gaan. Data integriteit lijkt mij belangrijker dan beschikbaarheid. Wat heb je aan data die beschikbaar is, maar zo het riool in kan?

[ Voor 17% gewijzigd door Q op 04-08-2014 15:45 ]

[Verwijderd]

Q schreef op maandag 04 augustus 2014 @ 15:31:
Dat ECC duurder is, is geen conspiracy theorie van bedrijven.

Als een aantal managers bijeen komen om een strategie te bespreken die heimelijk inbreuk maakt op de belangen van andere mensen, is dat wel degelijk een samenzwering, alleen noemen we het een 'strategie' omdat kapitalisme een vriendelijk gezicht moet hebben. Yankee traders, nietwaar?

Je hebt meer bitjes nodig om die extra parity info in op te slaan, dus voor de zelfde capaciteit heeft is meer fysiek geheugen nodig. Het prijsverschil is tientjes werk.

Afhankelijk van 8 chips per module is het 1/8e duurder; bij 16 chips slechts 1/16e. We praten dan over euro's; inderdaad misschien 10-20 euro als je veel geheugen neemt. Maar het staat natuurlijk niet in verhouding tot de totale kosten zeker aangezien het een welkome en eigenlijk noodzakelijke aanvulling is, om net dat beetje extra stabiliteit en zekerheid te geven wat anno 2014 toch echt wel zou mogen.\

Ik vind het zelf onzinnig dat mensen wel ZFS gaan gebruiken en blijkbaar zo paranoide zijn dat ze ZFS checksums willen gebruiken, maar dan geen ECC geheugen gaan gebruiken.

Het gebruik van ZFS is paranoïde? NTFS biedt helemaal geen bescherming, niet tegen corruptie en niet tegen bad sectors. En legacy RAID5 kan heel onbetrouwbaar zijn. Veel mensen verliezen hun data door dit soort legacy opslag. Dus paranoide is het helemaal niet. Hoeveel mensen verliezen hun kostbare data door gemis aan ECC? Ik heb er nog nooit van gehoord; wil niet zeggen dat het niet gebeurt maar de frequentie ligt natuurlijk in een heel andere orde van grootte.

Wat heeft het voor zin om checkums los te laten op garbage? Het geeft een vals gevoel van veiligheid.

Nee hoor; je merkt namelijk dat de file corrupt is. Dat wil zeggen, de checksum is corrupt en dus wordt de file afgekeurd. Dat zie je keurig in de zpool status -v output en je kunt dus zien om welk bestand het gaat. Meestal niet zo belangrijk, maar fijn dat je weet om welk bestand het gaat. Kun je van backup herstellen als het een belangrijk bestand was, of negeren als het niet belangrijk was. Maar errordetectie is zeker voor thuisgebruikers nog belangrijker dan errorcorrectie. Geeneens weten dat je bestanden corrupt zijn is.... funest.

Als je vindt dat ECC niet nodig is voor een thuis nas, dan is ZFS ook niet nodig voor een thuis NAS, is mijn stelling.

Prima, maar dat vind ik dus grote onzin. Dat is zoiets als, als je niet dezelfde veiligheid hanteert als een grote bank of kerncentrale, dan moet je maar gelijk voor het allerslechtste gaan. Complete onzin. Je gaat toch ook geen 20 bodyguards om je fiets heen plaatsen? Gewoon een slot van 50 euro is prima. Does the trick.

[Ultra]

Verwijderd schreef op maandag 04 augustus 2014 @ 15:07:
[...]

Wie zegt dat?

Niemand heeft het zo gezegd, maar de tendens voor mijn posts was dat ECC niet thuishoort in een DIY NAS. De nuance die inmiddels is aangebracht was nodig wat mij betreft.

[Verwijderd]

Het is een mooie aanvulling zeker voor je NAS. Ik zou ook graag ECC hebben. Maar soms wordt gezegd dat je wel gek bent als je geen ECC hebt als je voor ZFS gaat. En dat is dus echt paniekvoetbal. Je hebt het harder nodig als je geen ZFS draait.

[Verwijderd]

Verwijderd schreef op maandag 04 augustus 2014 @ 15:07:
[...]

Wie zegt dat?


[...]

ZFS heeft in mijn geval alle checksum errors gecorrigeerd zonder permanente corruptie. Wel tijdelijke corruptie, maar door de redundantie met een latere scrub gewoon weer gecorrigeerd. Dat betekent dat ZFS ook tegen RAM bitflips een vorm van bescherming biedt. Maar niemand claimt dat dat 100% is.

Het belangrijkste risico is dat de checksums verkeerd worden aangemaakt; daarmee is die file direct corrupt, onafhankelijk van de data op de disks en welke redundantie werd gebruikt.

Maar doen alsof een RAM bitflip gelijk je ZFS pool om zeep helpt is pure onzin. Het is theoretisch vast mogelijk dat een combinatie van bitflips op het verkeerde moment/plek inderdaad ernstige gevolgen kan hebben, maar ZFS kan prima tegen een stootje. Als je een thuisgebruiker bent, kun je prima zonder ECC.

Dat gezegd hebbende, vind ik dat iedere computer over ECC RAM dient te beschikken. Het is technisch onjuist om voor een euro die bescherming weg te laten. Maar het is een politiek-economisch-strategische keuze van de grote bedrijven zoals Intel om flink geld te vragen voor ECC, om aan productsegregatie te doen, zodat zakelijke klanten flink meer moeten betalen. Ze willen niet dat klanten met poen goedkoop consumentenspul kopen. Helaas, zo zit de wereld van het grote geld in elkaar. Dus je moet afwegingen gaan maken.

Een Core i3 met C226 chipset is prima betaalbaar en ondersteunt ECC. Als je ZFS wil voor de veiligheid, zijn er weinig >goede< redenen om niet voor ECC te gaan. Vanaf Haswell understeunen zelfs bijna alle i3 processors ook AES-NI. Je betaald voor een ECC systeem dus niet wezenlijk meer dan voor een non-ECC systeem.

Als je voor extreem grote opslag gaat zit je al snel aan de 32GB limiet en kom je bij s2011 en heb je registered ECC geheugen. Supermicro heeft een leuk single socket s2011 bordje met support voor 256MB Registered ECC geheugen. Maar dan hebben we het wel over andere prijzen.

Overigens in jouw voorbeeld is alleen de data gered die vooraf al goed op het systeem stond. Zoals je zelf al aangeeft nieuwe data zal vanaf het begin een foute checksum meekrijgen en niet als defect herkend worden.

tl;dr Gezien het geringe prijsverschil is het niet logisch om geen ECC te gebruiken en het extra risico te nemen.

[azerty]

Verwijderd schreef op maandag 04 augustus 2014 @ 16:10:
[...]

Een Core i3 met C226 chipset is prima betaalbaar en ondersteunt ECC. Als je ZFS wil voor de veiligheid, zijn er weinig >goede< redenen om niet voor ECC te gaan. Vanaf Haswell understeunen zelfs bijna alle i3 processors ook AES-NI. Je betaald voor een ECC systeem dus niet wezenlijk meer dan voor een non-ECC systeem.

Als je voor extreem grote opslag gaat zit je al snel aan de 32GB limiet en kom je bij s2011 en heb je registered ECC geheugen. Supermicro heeft een leuk single socket s2011 bordje met support voor 256MB Registered ECC geheugen. Maar dan hebben we het wel over andere prijzen.

Overigens in jouw voorbeeld is alleen de data gered die vooraf al goed op het systeem stond. Zoals je zelf al aangeeft nieuwe data zal vanaf het begin een foute checksum meekrijgen en niet als defect herkend worden.

tl;dr Gezien het geringe prijsverschil is het niet logisch om geen ECC te gebruiken en het extra risico te nemen.

Zelfs een Intel Pentium G3220 heeft ECC ondersteuning

[Verwijderd]

wsitedesign schreef op maandag 04 augustus 2014 @ 16:16:
[...]


Zelfs een Intel Pentium G3220 heeft ECC ondersteuning

Maar die heeft dan weer geen AES-NI support, dus als je encryption wil doe je een zware trade off voor die € 50 die een i3 meer kost. (Je levert ca 33% performance in)

BTW, als je bewust bent wat de keuze voor geen ECC betekent en je bouwt met je oude hardware een NAS dan krijg je opzich een prima NAS zonder ECC. Maar dat is de enige omstandigheid waaronder ik geen ECC zou nemen.

@hieronder: Ah ok, goed punt. Als je toch geen encryption gebruikt dan kan je met die pentium en het juiste geheugen en moederbord een goedkoper NAS systeem bouwen als sommige voorstelling zonder ECC die hier voorbijkomen.

[ Voor 43% gewijzigd door Verwijderd op 04-08-2014 16:24 ]

[azerty]

Verwijderd schreef op maandag 04 augustus 2014 @ 16:18:
[...]

Maar die heeft dan weer geen AES-NI support, dus als je encryption wil die je een zware trade off voor die € 50 die een i3 meer kost.

Was gewoon om aan te geven dat het niet kiezen van ECC niet afgeschoven kan worden op "kostprijs" van intel processors, niet meer, niet minder. Als je dan idd encryption wilt, ben je beter af met een i3

[TrsvK]

Mwa, het kostprijs verschil zit vooral in de combinatie van het moederbord en het geheugen. Waar veel mensen goed uit de voeten zouden kunnen met een NAS van rond de 200 euro voor een non-ecc ben je al snel het dubbele kwijt voor een NAS met ecc geheugen.

Het is dus maar net hoeveel waarde je hecht aan de integriteit van je data en waarvoor je de NAS gebruikt.

[Q]

Verwijderd schreef op maandag 04 augustus 2014 @ 15:46:
Als een aantal managers bijeen komen om een strategie te bespreken die heimelijk inbreuk maakt op de belangen van andere mensen, is dat wel degelijk een samenzwering, alleen noemen we het een 'strategie' omdat kapitalisme een vriendelijk gezicht moet hebben. Yankee traders, nietwaar?

Pfff.

Afhankelijk van 8 chips per module is het 1/8e duurder; bij 16 chips slechts 1/16e. We praten dan over euro's; inderdaad misschien 10-20 euro als je veel geheugen neemt. Maar het staat natuurlijk niet in verhouding tot de totale kosten zeker aangezien het een welkome en eigenlijk noodzakelijke aanvulling is, om net dat beetje extra stabiliteit en zekerheid te geven wat anno 2014 toch echt wel zou mogen.\

Precies, dus ECC geheugen is tientjes werk. Dus waar hebben we het over. Als je data niet die paar tientjes waard is, tja.

Het gebruik van ZFS is paranoïde? NTFS biedt helemaal geen bescherming, niet tegen corruptie en niet tegen bad sectors. En legacy RAID5 kan heel onbetrouwbaar zijn. Veel mensen verliezen hun data door dit soort legacy opslag. Dus paranoide is het helemaal niet. Hoeveel mensen verliezen hun kostbare data door gemis aan ECC? Ik heb er nog nooit van gehoord; wil niet zeggen dat het niet gebeurt maar de frequentie ligt natuurlijk in een heel andere orde van grootte.

Nee CiPHER, je leest + interpreteert mijn opmerking verkeerd. Waarschijnlijk reageer je vooral op het woord paranoide, wat ik in dit geval niet als negatief gebruik. Paranoide = in deze context: dat je dermate veel waarde hecht aan je data dat je bereid bent om daarvoor extra moeite te doen om die data veilig te stellen en daar eventueel ook meer voor wilt betalen. Je data is niet zomaar modder, maar echt waardevol.

Door gemis aan ECC verlies je zeker data, zelfs op grotere schaal, maar we meten en monitoren het niet.
Voor legacy file systems is ECC minder risico vol omdat ze lang niet zo op het ram leunen voor schrijven,
of slechts een klein deel gebruiken, wat het risico op het treffen van rot ram kleiner maakt.

Storingen door geheugenfouten zijn altijd lastig op te sporen en geven vaak vage symptomen. En ook niet alle data hoeft meteen corrupt te zijn.

Nee hoor; je merkt namelijk dat de file corrupt is.

NEIN NEIN NEIN!

Vanuit het netwerk via het corrupte RAM op disk wordt geschreven is het al te laat. Dat kan ZFS niet zien.
Daar gaat het om.

Maar errordetectie is zeker voor thuisgebruikers nog belangrijker dan errorcorrectie. Geeneens weten dat je bestanden corrupt zijn is.... funest.

Beter 1 vogel in de hand dan 10 in de lucht ja, maar in je voorbeeld kom je er nooit achter. Garbage in, garbage out.

Prima, maar dat vind ik dus grote onzin. Dat is zoiets als, als je niet dezelfde veiligheid hanteert als een grote bank of kerncentrale, dan moet je maar gelijk voor het allerslechtste gaan. Complete onzin. Je gaat toch ook geen 20 bodyguards om je fiets heen plaatsen? Gewoon een slot van 50 euro is prima. Does the trick.

Ik snap niet hoe je mijn opmerking onzin vind, want je analogie sluit precies aan met wat ik zeg.

Grote bank of kerncentrale: ECC en ZFS (data is belangrijk)
Fiets: NTFS / XFS (een slot van 50 euro is prima?).

Als jij je data zo waardevol vind dat je liever ZFS gebruikt dan NTFS/XFS/EXT4, dan is je data ook die paar tientjes waard voor ECC geheugen, zou ik zeggen.

Ik vind het fundamenteel fout om te zeggen tegen mensen in dit topic dat ZFS ook prima OK is zonder ECC geheugen. Ik vind dat een oneerlijk advies.

Ik zeg niet dat het zo is, maar ik krijg de indruk dat het ZFS evangelie verspreiden belangrijker is dan daadwerkelijk mensen een goede oplosing bieden. Want ECC geheugen is moeilijk en werpt een drempel op voor nieuwe ZFS gebruikers, ook al is het maar een paar tientjes.

http://nex7.blogspot.nl/2...ecc-ram-great-debate.html

There is no debate here. None. Within the realm of ZFS (and, if you ask me, in the realm of all generic computing, too, but that gets close to being an actual debate), if you think non-ECC RAM can compete with ECC RAM, you are mistaken. If you think there's a risk/reward analysis here, you're correct. The risk is not gigantic, and there's a real cost to alleviating that risk. You have to decide if that cost is worth alleviating that risk. You should not downplay that risk, or try to tell others it's a non-risk, and certainly shouldn't suggest mitigation schemes to them that don't even work. This does a great disservice to everyone.

Wat wel eerlijk is, is vertelen dat ECC voor ZFS zeker is aan te raden. Als je disks rotte data introduceren ben je beschermd door ZFS, maar als je geheugen rotte data introduceert niet.

En ik voel nu aan komen dat RAM fouten ook gebagataliseerd worden, maar als ik iets wel een conspiracy zou willen noemen is dat de industrie geen ECC geheugen in gewone pc's stopt (niet waar, maar you catch my drift). In server land worden geen computers verkocht zonder ECC. Guess why.

ZFS is geschreven met als core fundament het RAM geheugen. Daar gebeurt alles, met de transactie groups, het reorderen voor serieel wegschrijven, RAM = alles voor ZFS. Zeker in de tijd dat 2GB al veel geheugen was, waren de RAM requirements van ZFS bijna waanzinnig (minimum 8G) voor thuis.
ZFS vertrouwt het RAM, er is geen direct mechanisme om rot RAM te detecteren. RAM = trusted.
Om dan zo te bezuinigen op RAM is gewoon stom.

Nog een quote:

If you choose to use non-ECC RAM, you open yourself up to a new vector for data corruption/loss/downtime/errors/etc, one that could (rarely) even cause you to lose your entire filesystem, and one ZFS does not (cannot) resolve for you. Indeed, one it likely can't even see at all. If you choose to employ non-ECC RAM, or are forced to do so because of circumstance or environmental constraint, that's potentially understandable (and even acceptable) - but do not then attempt to validate or explain away that choice with pseudoscience or downplaying the risk you've added. You are using an inferior solution with an extra vector for data corruption/loss that ECC RAM solutions simply do not have. It is that simple.

CiPHER, hoe kun je deze twee zinnen achter elkaar schrijven?

Als je een thuisgebruiker bent, kun je prima zonder ECC.
Dat gezegd hebbende, vind ik dat iedere computer over ECC RAM dient te beschikken.

Firedrunk:

Dat is allang ontkracht door 1 van de main Dev's van ZFS. ECC helpt, het is niet verplicht.
De alarmbellen van ZFS zullen alleen wat sneller afgaan omdat het corruptie op disk ziet die waarschijnlijk veroorzaakt word door je geheugen, maar de geoefende Systeembeheerder is daar snel genoeg achter.

Thuis gebruikers zijn meestal geen geoefende systeem beheerders. Geoeffende systeem beheerders gebruiken alleen ECC . Corrupt RAM kan best een tijdje onopgemerkt je data corrumperen. En daar zal ZFS niet op triggeren.

[ Voor 20% gewijzigd door Q op 04-08-2014 18:44 ]

[MvL]

Een noob vraag.., hoe betrouwbaar is zfs? Hoe groot is de kans dat ik data kwijtraak ten opzichte van raid (mdadm). Ik zoek een eerlijk antwoord geen fanboy antwoord.

[Q]

Ik ben zeker geen fanboy van ZFS maar ZFS is betrouwbaar. De BSD implementatie (gok) lijkt mij het meest betrouwbaar en bevat de nieuwste features. Maar ZFS on Linux, wat ik ga draaien, werkt ook uitstekend.

ZFS biedt veel betere bescherming van de integriteit van je data dan mdadm door checksums.

[FireDrunk]

At hierboven, zoals ik altijd al zeg: ECC helpt in *alle* gevallen om je server beter te laten werken, of je nou Windows draait, Linux, BSD, of hell, van mij part draai je nog DOS... Zelfs daar werkt ECC (voor zover ik weet)....

De discussie is niet of je ECC moet gebruiken... Als je aan mij vraagt, ik wil een veilige server bouwen die veel doet, moet ik dan ECC gebruiken? Dan is mijn antwoord volmondig JA...

Als je recht toe rechtaan vraagt, heb ik ECC nodig om ZFS te kunnen gebruiken, dan is mijn antwoord: NEE.

Het is een beetje als zeggen, kan ik met mijn 4x4 net zo goed op de snelweg rijden als op het zand... Nee, maar het werkt wel.

Doet hij waar hij goed in is? Ja en nee... het brengt je van A naar B... Doet het ding het op de beste manier mogelijk. Nee dat niet...

ZFS met ECC is de beste optie, maar het is technisch niet verplicht.

beter gezegd: ZFS heeft ECC net zo hard nodig als elk ander Filesystem..

@Q, je hebt zeker gelijk dat eindgebruikers ECC zouden moeten nemen als ze geen gezeur willen. Maar dan zeg ik. Investeer liever in een remote backup... Dat werkt 100000x keer beter dan een beetje ECC geheugen.

[Q]

Als je rechtstreeks vanaf je PC remote backups maakt naar een cloud provider als backblaze, dan denk ik dat die data veiliger staat dan bij je thuis op een ECC doos omdat je dan nog niet beschermd bent tegen brand.
Maar wat je eigenlijk zegt is: stuur je data naar de ECC machines van backblaze .

[FireDrunk]

Ja, Indirect wel. Maar dat is niet het kernpunt. Wat ik bedoel is, dat er voor elk risico een passende oplossing is... Voor bitrot is dat ZFS, voor geheugenflips is dat ECC, maar voor algehele malaise, is dat remote backup... DAT werkt veel beter dan alle voorgaande spullen. En als je bang bent voor de remote integriteit kan je checksummen (PAR).

[Q]

Ik denk niet dat het fair is om zo risico's te mixen. Remote backup beschermt niet tegen bit flips. Garbage in = garbage out.

Technisch werkt ZFS zonder ECC RAM.
Technisch werkt een 24 drive RAID5 ook.

Maar beiden geven een vals gevoel van veiligheid.

[Verwijderd]

Ik heb kennelijk gelijk als ik zeg dat errordetectie flink wordt ondergewaardeerd. Je hebt geen ECC nodig, als je kunt leven met errordetectie en als er in uitzonderlijke gevallen een paar files corrupt raken, en in astronomisch onwaarschijnlijke gevallen - net zoals kometen en andere rampen - je pool corrupt kan raken. Dat risico sluit je overigens ook niet uit met ECC-geheugen, maar je verkleint het wel.

Heb je dus extreem hoge eisen aan betrouwbaarheid, dan heb je ECC absoluut nodig. Ben je een thuisgebruiker en wil je hoogwaardige bescherming voor je gegevens, dan is ZFS zonder ECC zeker al afdoende. Het simpelweg kunnen weten wanneer er corruptie plaatsvindt, is vaak al voldoende bescherming. Echt belangrijke bestanden kun je dan vanaf backup herstellen en minder belangrijke bestanden is het fijn om te weten wat je precies mist. Ook voorkom je dat corruptie naar je backups kan vloeien.

Kortom, ECC in combinatie met ZFS is zeker geen vereiste; ik deel je mening dus niet.

[Ultra]

Je bent het dus niet met die blog eens?

quote: http://nex7.blogspot.nl/2...ecc-ram-great-debate.html

Hint: If you think you can mitigate them [=risks] by taking more frequent backups of your ZFS data, you do not understand the risks.

[Paul]

Niemand heeft het over 'mitigate' -> gelijk maken aan nul.

De kans dat je hele pool stuk gaat door geheugenfouten is zo klein dat je dat je er voor kunt kiezen dat risico te accepteren. Net zoals je als thuisgebruiker accepteert dat je, wanneer er een vliegtuig op je huis stort, je NAS offline gaat.

Alles is een kosten/baten-analyse, en ECC is nu eenmaal duurder. Zoals 'jullie' graag blijven strooien: garbage in, garbage out. Hebben jullie je clients ook allemaal van ECC voorzien? Of accepteer je dat je werkstation misschien garbage naar je NAS gaat sturen omdat de kans daarop zo klein is?

[FireDrunk]

Jij snapt het!

[Verwijderd]

Paul schreef op dinsdag 05 augustus 2014 @ 11:54:
De kans dat je hele pool stuk gaat door geheugenfouten is zo klein dat je dat je er voor kunt kiezen dat risico te accepteren. Net zoals je als thuisgebruiker accepteert dat je, wanneer er een vliegtuig op je huis stort, je NAS offline gaat.

Alles is een kosten/baten-analyse, en ECC is nu eenmaal duurder. Zoals 'jullie' graag blijven strooien: garbage in, garbage out. Hebben jullie je clients ook allemaal van ECC voorzien? Of accepteer je dat je werkstation misschien garbage naar je NAS gaat sturen omdat de kans daarop zo klein is?

Niemand heeft ooit gezegd dat het geen kosten/baten afweging en dus een keuze was. Het is alleen een rare keuze om wel ZFS te kiezen en dan niet voor ECC. Temeer aangezien de extra kosten reuze mee vallen.

Daarnaast stappen mensen eraan voorbij dat geheugen fouten zonder ECC in een zelf healend systeem voor voortschrijdende corruptie zorgen. Bestanden die goed zijn op disk kunnen fout 'gerepareerd' worden door foute checksums/errorcorrectie data.

Een niet zelfhealend systeem met alleen detectie zal een fout constateren, maar als je uiteindelijk het geheugen vervangt staat het nog correct op disk! Met andere woorden ZFS heeft zonder ECC geheugen een extra risico tov andere systemen.

Je geeft dus veel extra geld uit aan geheugen om ZFS te kunnen gebruiken (andere filesystems kunnen met een fractie van het geheugen werken), maar niet dat kleine beetje extra voor ECC. Als geld je issue is, ga dan voor een klassiek RAID6 systeem met iets als XFS en je NAS heeft met 4GB geheugen al ruim voldoende.

[Q]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 13:10:
[...]

Niemand heeft ooit gezegd dat het geen kosten/baten afweging en dus een keuze was. Het is alleen een rare keuze om wel ZFS te kiezen en dan niet voor ECC. Temeer aangezien de extra kosten reuze mee vallen.

Daarnaast stappen mensen eraan voorbij dat geheugen fouten zonder ECC in een zelf healend systeem voor voortschrijdende corruptie zorgen. Bestanden die goed zijn op disk kunnen fout 'gerepareerd' worden door foute checksums/errorcorrectie data.

Een niet zelfhealend systeem met alleen detectie zal een fout constateren, maar als je uiteindelijk het geheugen vervangt staat het nog correct op disk! Met andere woorden ZFS heeft zonder ECC geheugen een extra risico tov andere systemen.

Je geeft dus veel extra geld uit aan geheugen om ZFS te kunnen gebruiken (andere filesystems kunnen met een fractie van het geheugen werken), maar niet dat kleine beetje extra voor ECC. Als geld je issue is, ga dan voor een klassiek RAID6 systeem met iets als XFS en je NAS heeft met 4GB geheugen al ruim voldoende.

Dit is exact het probleem en geeft precies mijn standpunt weer.

Verwijderd schreef op dinsdag 05 augustus 2014 @ 11:11:
Ik heb kennelijk gelijk als ik zeg dat errordetectie flink wordt ondergewaardeerd. Je hebt geen ECC nodig, als je kunt leven met errordetectie en als er in uitzonderlijke gevallen een paar files corrupt raken, en in astronomisch onwaarschijnlijke gevallen - net zoals kometen en andere rampen - je pool corrupt kan raken. Dat risico sluit je overigens ook niet uit met ECC-geheugen, maar je verkleint het wel.

Nog voordat ZFS met data aan de slag gaat komt het op rot ram terecht. Gaat ZFS dan checksummen dan checksumt ZFS garbage. Zo komt ZFS er nooit achter dat data corrupt is.

Paul schreef op dinsdag 05 augustus 2014 @ 11:54:
De kans dat je hele pool stuk gaat door geheugenfouten is zo klein dat je dat je er voor kunt kiezen dat risico te accepteren. Net zoals je als thuisgebruiker accepteert dat je, wanneer er een vliegtuig op je huis stort, je NAS offline gaat.

En weer probeert men de risico's te ontkennen of te bagataliseren. De kans dat een vliegtuig op je huis komt is kleiner dan RAM of Storage fouten.

Hebben jullie je clients ook allemaal van ECC voorzien? Of accepteer je dat je werkstation misschien garbage naar je NAS gaat sturen omdat de kans daarop zo klein is?

Snap je dat dit precies het argument zou zijn om ZFS dus maar helemaal te laten zitten? Als je op de client geen ECC draait, wat boeit ZFS dan nog? Garbage in, garbage out.

Je hebt dus je client en je NAS. Ga je op twee devices het risico lopen of op 1 device?
De machine waar jij je data op gaat bewaren moet een bastion zijn van betrouwbaarheid.
Als je dat niet zo uitmaakt is er ook geen reden om ZFS te draaien.

[ Voor 44% gewijzigd door Q op 05-08-2014 14:15 ]

[FireDrunk]

Uh, jullie gaan er van uit dat ZFS met terugwerkende kracht data kapot gaat maken? Hoe kom je daar bij? ZFS heeft dubbele checksums, zowel over data als metadata. Als beide niet overeen komen wordt er helemaal niets naar disk geschreven!

Als er dus zo veel corruptie voor komt dat er data substantieel verkeerd binnen komt, stopt ZFS er gewoon mee...

[Q]

FireDrunk schreef op dinsdag 05 augustus 2014 @ 14:11:
Uh, jullie gaan er van uit dat ZFS met terugwerkende kracht data kapot gaat maken?

Nee.

Ja eigenlijk wel, daar lijkt een scenario voor te zijn:

https://pthree.org/2013/1...y-you-should-use-ecc-ram/

En ik vind deze quote mooi:

ZFS parity data, checksums, and physical data all need to match. When they don't, repairs start taking place. If it is corrupted out the gate, due to non-ECC RAM, why are you using ZFS again?

[ Voor 54% gewijzigd door Q op 05-08-2014 14:26 ]

[Davidshadow13]

Om even in te breken op het non-ECC vs ECC verhaal. Ik ben van plan om mijn huidige server te vervangen door iets zuinigers. Draai nu nog op een E8600 met niet al te zuinig mobo en voor 24/7 gebruik is dat gewoon zonde van het geld.

Nu heb ik twee configuraties in mijn hoofd. Een op basis van een AMD Kabini APU en één op basis van een Intel Celeron met de nieuwe ECO Moederborden van MSI.

#	Product	Prijs	Subtotaal
1	AMD Athlon 5350 Boxed	€ 47,-	€ 47,-
1	ASRock AM1B-ITX	€ 27,-	€ 27,-
1	Crucial CT51264BA160BJ	€ 31,-	€ 31,-
Bekijk collectie Importeer producten		Totaal	€ 136,90

Of dus deze:

#	Product	Prijs	Subtotaal
1	Intel Celeron G1850 Boxed	€ 45,50	€ 45,50
1	MSI H81M Eco	€ 54,-	€ 54,-
1	Crucial CT51264BA160BJ	€ 31,-	€ 31,-
Bekijk collectie Importeer producten		Totaal	€ 162,40

De bedoeling is om ZFS te draaien op FreeNAS in een RAIDZ configuratie (3x2TB). Allereerst wordt die ASMedia chipset die ASRock gebruikt voor de 2 extra SATA poorten ondertussen al ondersteund in FreeNAS. Want ik lees overal tegenstrijdige berichten over dat het niet zou werken maar ik zie dat bordje ook hier vaak langskomen voor een FreeNAS build.

Verder hoe zuinig is zo'n G1850 nu echt in combinatie met zo'n ECO moederbord. Ik weet dat die APU's van AMD heel zuinig zijn zo'n 17/35 watt (idle/load). En door het SoC design zeker zuiniger is dan een aparte CPU en moederbord. Maar zijn de verschillen tijdens idle zo groot dan. Onder load verwacht ik zeker dat zo'n G1850 combi wel 50 watt trekt, maar bij 24/7 is 80% natuurlijk idle gebruik. Kan ik dan nog een verbruik van <20 watt verwachten? Aangezien bijvoorbeeld alleen de chipset op het mobo zelf al 5watt gebruikt. MSI geeft zelf een verbruik van zo'n 17W aan maar het is mij niet duidelijk of dit inclusief CPU is?

[Paul]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 13:10:
Niemand heeft ooit gezegd dat het geen kosten/baten afweging en dus een keuze was. Het is alleen een rare keuze om wel ZFS te kiezen en dan niet voor ECC. Temeer aangezien de extra kosten reuze mee vallen.

2x zo duur vind ik niet echt 'reuze mee vallen'. Ik kan (in de goedkope range) geen enkel moederbord gevonden krijgen waar ECC op wordt ondersteund, dus hoewel de CPU dus slechts 50% duurder is en het geheugen 16% is het moederbord minimaal 3x zo duur...

Zodra je meer richting serverhardware (vanwege de snelheid of het aantal PCIe-sloten bijvoorbeeld) gaat dan krijg je het er (vrijwel) gratis bij, eens, maar veel van de setups die hier langskomen zitten aan de onderkant van de markt

Je geeft dus veel extra geld uit aan geheugen om ZFS te kunnen gebruiken (andere filesystems kunnen met een fractie van het geheugen werken)

Wait what? ZFS werkt ook gewoon met 4 of 8 GB, en die had ik sowieso wel in mijn NAS gezet; ook andere filesystems / OS'en doen aan caching.

Q schreef op dinsdag 05 augustus 2014 @ 13:44:
Nog voordat ZFS met data aan de slag gaat komt het op rot ram terecht. Gaat ZFS dan checksummen dan checksumt ZFS garbage. Zo komt ZFS er nooit achter dat data corrupt is.

Dat is niet anders dan met ETX4, NTFS etc etc. Daar hoor ik echter ook niemand roepen dat ECC zo goed als verplicht is.

En weer probeert men de risico's te ontkennen of te bagataliseren

Euhm, nee? Die kans IS gewoon klein. Dat deze groter is dan de kans dat een vliegtuig op je huis komt wil ik best van je aannemen, dat maakt die kans er echter niet groter op... Jullie doen vooral maar zo veel mogelijk je best het risico zo groot mogelijk op te blazen, dat is iets heel anders.

Snap je dat dit precies het argument zou zijn om ZFS dus maar helemaal te laten zitten?

Zonder autogordel loop je het risico te overlijden bij een aanrijding, met gordel ook. Zullen we dan gordels (en airbags, en ABS, en motoren die naar onderen schuiven in plaats van dóór de passagiers heen te maaien) maar helemaal uit de auto slopen? Of zorgt het er, ondanks dat dit het risico niet helemaal wegneemt, misschien stiekem toch voor dat de kans dat je het overleeft groter wordt?

Computers werken dan misschien wel met nulletjes en eentjes, dat wil niet zeggen dat de hele wereld zo werkt. Zet op de goede volgorde qua betrouwbaarheid:
1) mirror, NTFS, wel ECC
2) Stukje papier midden in een bosbrand met daarop nulletjes en ééntjes
3) mirror, ZFS, wel ECC
4) mirror, ZFS, geen ECC

Als ik jullie mag geloven is ZFS+ECC het walhalla, vervolgens de mirror met NTFS, dan het brandende papiertje en honderd kilometer verderop komt een keer ZFS zonder ECC voorbij qua betrouwbaarheid.

[ Voor 4% gewijzigd door Paul op 05-08-2014 14:55 ]

[Q]

Je overdrijft de boel en trekt de boel uit zijn verband. Ook bagataliseer je de risico's weer met je analogieen.

You should not downplay that risk, or try to tell others it's a non-risk, and certainly shouldn't suggest mitigation schemes to them that don't even work. This does a great disservice to everyone.

ZFS zonder ECC draaien is alsof je in een auto stapt met remmen maar zonder gordels.

Dat kan een tijdje goed gaan maar remmen lossen niet het probleem op dat gordels oplossen.

Nieuwkomers worden hier verteld dat ze geen gordels nodig hebben voor hun auto en daar ben ik het niet zo mee eens. Ik vind dat een disservice en een oneerlijke voorstelling van zaken.

Mensen kunnen nog steeds besluiten om geen ECC te kopen omdat ze die oplossing te duur vinden en dat is dan hun goed recht. Maar je neemt dan wel een risico wat je niet zomaar kunt wegwuiven / bagataliseren.

[ Voor 36% gewijzigd door Q op 05-08-2014 15:12 ]

[Paul]

Q schreef op dinsdag 05 augustus 2014 @ 15:05:
Je overdrijft de boel en trekt de boel uit zijn verband.

Je overdrijft de boel en trekt de boel uit zijn verband. Je overdrijft schromelijk, zelfs in je allereerste zin erna:

ZFS zonder ECC draaien is alsof je in een auto stapt met gordels maar zonder remmen.

Weet je zeker dat je niet zit te trollen?

Ook bagataliseer[sic] je de risico's weer

Ja doei... Kom eerst eens met getallen en onderbouwing voor die apocalyps van je. Wie is er hier nu dingen uit zijn verband aan het trekken danwel overdrijven (of het tegenovergestelde, bagatelliseren)? Ik kan je garanderen dat je in een auto zonder remmen al bij vrijwel de eerste bocht of het eerste verkeerslicht bij een ongeval betrokken raakt, en er zijn HEEL VEEL bochten en verkeerslichten.

Daarentegen zijn er HEEL VEEL mensen die ZFS draaien zonder ECC, en echt heel vreemd, ik snap er niks van, maar die hebben (bijna) allemaal nog een werkende pool met bestanden die ze gewoon kunnen lezen

Sowieso mag je me even aanwijzen waar ik 'mitigation schemes suggest'...

[ Voor 8% gewijzigd door Paul op 05-08-2014 15:14 ]

[Q]

Waarom worden servers alleen verkocht met ECC geheugen?

Dat je auto geen gordels heeft wil niet meteen zeggen dat je meteen bij de eerste de beste auto rit sterft.

http://forums.freenas.org...on-ecc-ram-and-zfs.15449/

[Verwijderd]

Davidshadow13 schreef op dinsdag 05 augustus 2014 @ 14:29:
Om even in te breken op het non-ECC vs ECC verhaal.

Ah gelukkig.

Ik ben van plan om mijn huidige server te vervangen door iets zuinigers. Draai nu nog op een E8600 met niet al te zuinig mobo en voor 24/7 gebruik is dat gewoon zonde van het geld.

Nu heb ik twee configuraties in mijn hoofd. Een op basis van een AMD Kabini APU en één op basis van een Intel Celeron met de nieuwe ECO Moederborden van MSI.

Neem ook Intel J1900 mee in je overweging; dit is de tegenhanger van AMD Kabini (Athlon 5350). Het is minder krachtig qua graphics, maar ook quadcore en doet het ongeveer evengoed als AMD maar dan met lager TDP (10W). Zo heb ik het SuperMicro X10SBA bordje met 6x SATA en dual Intel gigabit, zit ook een ingebouwde DC-DC voeding op. Erg leuk bordje en heb ik ook als redelijk zuinig getest.

Je geheugen zou ik zeker vervangen. 4GiB kun je overwegen als je niet voor 8GiB wilt gaan (wat mijn voorkeur is) maar CAS latency 11 op 1,5 volt is ouderwets; CAS latency 8 op 1,35 volt (Crucial tactical) of CAS9 op 1,35volt (Ballistix) is tegenwoordig de norm.

Verder hoe zuinig is zo'n G1850 nu echt in combinatie met zo'n ECO moederbord. Ik weet dat die APU's van AMD heel zuinig zijn zo'n 17/35 watt (idle/load). En door het SoC design zeker zuiniger is dan een aparte CPU en moederbord. Maar zijn de verschillen tijdens idle zo groot dan.

Nee; de losse chipset verbruikt wel iets. Maar de CPU zelf zit op minder dan 1W idle met energiebesparing. De vraag is vooral wat voor voeding je gebruikt; dat heeft waarschijnlijk de meeste invloed. Ga je niet voor PicoPSU dan zit je aan een hoger verbruik; op een kale configuratie bijna het dubbele verbruik; met schijven erbij in een realistischer scenario is het verschil zo'n 4 tot 5 watt. Dus als je een redelijk zuinige ATX-voeding neemt, kan het ook best. Maar met een laag-TDP mobo+cpu met 4 of minder schijven, kun je ook PicoPSU overwegen. Bijkomend voordeel is dat je geheel passief kunt draaien; zonder ventilatoren. Dat kan dan ook niet stuk gaan, wat ik ook een voordeel vindt. Bovendien zou je de kast helemaal stofdicht kunnen maken; mits je met je hittedissipatie goed uit komt; dat hangt af van je kast en locatie van de server. Op een zolderkamer kan het zomers flink warm worden, daar moet je rekening mee houden.

Onder load verwacht ik zeker dat zo'n G1850 combi wel 50 watt trekt, maar bij 24/7 is 80% natuurlijk idle gebruik.

Eerder 99%. Zelfs tijdens gebruik is je processor gedurende vele tussenpozen idle. Dus voor een ZFS NAS kun je uitgaan van 99%+ idle en dat is het enige wat telt qua energieverbruik/stroomkosten.

Wellicht vind je mijn stroommetingen interessant; ook met een Athlon 5350:
Stroomverbruik SuperMicro X10SBA
Stroomverbruik Processor+Moederbord+Geheugen
In dit topic heb ik nog metingen van Athlon 5350 ASRock bordje, moet je even zoeken op mijn naam en dan Laatste pagina of de voorgaande pagina.

Succes!

[Verwijderd]

Paul schreef op dinsdag 05 augustus 2014 @ 14:54:
[...]
2x zo duur vind ik niet echt 'reuze mee vallen'. Ik kan (in de goedkope range) geen enkel moederbord gevonden krijgen waar ECC op wordt ondersteund, dus hoewel de CPU dus slechts 50% duurder is en het geheugen 16% is het moederbord minimaal 3x zo duur...

Zodra je meer richting serverhardware (vanwege de snelheid of het aantal PCIe-sloten bijvoorbeeld) gaat dan krijg je het er (vrijwel) gratis bij, eens, maar veel van de setups die hier langskomen zitten aan de onderkant van de markt
[...]
Wait what? ZFS werkt ook gewoon met 4 of 8 GB, en die had ik sowieso wel in mijn NAS gezet; ook andere filesystems / OS'en doen aan caching.
[...]

Goedkoopste intel moederbord met ECC dat ik kon vinden was 150 euro. Je hebt dan wel meteen een moederbord met dual intel gigabit ethernet. En goede PCI-E uitbreiding (x4 slot bijvoorbeeld ipv alleen x16 en x1). Extra prijs ten opzichte van een kwalitatief goed non-ECC bord ca 50 euro, niet 3x zoveel.

CPU kan je een Pentium G3460 gebruiken als je geen interesse in encryptie hebt. Kost je dus niets extra tov geen ECC. Geheugen geef je al aan ca 16% prijsverschil. En er is verschil tussen ZFS kunnen gebruiken met 4G/8G en fatsoenlijke performance uit je NAS halen.

Vervolgens gooien mensen er 4x tot 6x 4TB schijven in die het prijspunt van het systeem volledig domineren.

En als het je echt te duur wordt (Die extra 150 euro!) heb je altijd nog AMD!

[Davidshadow13]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 15:17:

Neem ook Intel J1900 mee in je overweging; dit is de tegenhanger van AMD Kabini (Athlon 5350). Het is minder krachtig qua graphics, maar ook quadcore en doet het ongeveer evengoed als AMD maar dan met lager TDP (10W). Zo heb ik het SuperMicro X10SBA bordje met 6x SATA en dual Intel gigabit, zit ook een ingebouwde DC-DC voeding op. Erg leuk bordje en heb ik ook als redelijk zuinig getest.

Je geheugen zou ik zeker vervangen. 4GiB kun je overwegen als je niet voor 8GiB wilt gaan (wat mijn voorkeur is) maar CAS latency 11 op 1,5 volt is ouderwets; CAS latency 8 op 1,35 volt (Crucial tactical) of CAS9 op 1,35volt (Ballistix) is tegenwoordig de norm.

Ik heb even gekeken maar er zit toch nog wel een behoorlijk verschil is passmark scores bijvoorbeeld. De J1900 scoort 1976 punten en de 5350 ruim 2600. Ik zou ook graag 1 HD stream via Plex willen kunnen transcoden voor een tijdje voordat ik overga op DLNA. Plex raadt daarvoor aan minimaal 2000 punten in Passmark te hebben. Dan zou de J1900 net te licht zijn en kan ik de GPU power van de 5350 goed gebruiken.

De metingen van jouw met de 5350 die ik had gezien komen aardig overeen met wat ik gevonden had. Die 37,5 watt met 3 schijven is verder keurig. Nog beter dan ik had gelezen, daar was het alleen al 36 watt voor CPU + Moederbord in idle. Ik gebruik in mijn server nu nog een 420W 80+ Bronze voeding van Coolermaster, maar als die echt het dubbele zal gaan verbruiken is het inderdaad misschien handig om over te gaan op een PicoPSU of DC oplossing. Maar dat zal ik zelf we nameten dan.

Het geheugen zal ik naar gaan kijken en meteen aanpassen. Had eigenlijk gewoon deze gepakt omdat hij helemaal bovenaan stond, beetje uit luiheid .

Het lijkt mij verder wel duidelijk dat een G1850 oplossing niet alleen duurder is in aanschaf maar ook behoorlijk wat meer stroom gaat gebruiken i.c.m. moederbord en dat ik daarmee de <50 watt idle niet ga halen ben ik bang van.

Verder is het goed om te lezen dat die ASMedia SATA controller dus geen problemen moet geven in FreeBSD op dit moment. Met de laatste versie van FreeNAS zou dat probleem dus ook opgelost moeten zijn. Dan zou dat dus de beste keuze zijn op dit moment. Eventueel kan ik dan later nog uitbreiden met een nieuw bordje als ik 6+ SATA poorten nodig heb. Dat is eigenlijk het enige voordeel van een normale Haswell oplossing. Want een C2550 oplossing is mooi maar wel twee keer zou duur dus dat vind ik een beetje zonde op dit moment.

[DXaroth]

Verwijderd schreef op dinsdag 05 augustus 2014 @ 15:27:
[...]

Goedkoopste intel moederbord met ECC dat ik kon vinden was 150 euro. Je hebt dan wel meteen een moederbord met dual intel gigabit ethernet. En goede PCI-E uitbreiding (x4 slot bijvoorbeeld ipv alleen x16 en x1). Extra prijs ten opzichte van een kwalitatief goed non-ECC bord ca 50 euro, niet 3x zoveel.

CPU kan je een Pentium G3460 gebruiken als je geen interesse in encryptie hebt. Kost je dus niets extra tov geen ECC. Geheugen geef je al aan ca 16% prijsverschil. En er is verschil tussen ZFS kunnen gebruiken met 4G/8G en fatsoenlijke performance uit je NAS halen.

Vervolgens gooien mensen er 4x tot 6x 4TB schijven in die het prijspunt van het systeem volledig domineren.

En als het je echt te duur wordt (Die extra 150 euro!) heb je altijd nog AMD!

Het ene moment gebruik je harde getallen (50 euro), op het andere moment gebruik je procenten (16%) ... wellicht wil je dat aanpassen dat, op 8GB sticks, het verschil grofweg 10-20 euro is T.o.v. non-ECC.. de goedkoopste in pricewatch is 60 euries voor Non-ECC, en 72 voor ECC...

En ja, ik snap niet echt waarom mensen een probleem gaan maken over nog geen 100 euro meerkosten aan extra data-beveiliging, maar een raidz2 array maken met schijven die 150 euro kosten is de gewoonste zaak van de wereld (waarbij je dus feitelijk 300 euro meer betaald voor extra data veiligheid).. bedoel, kom op mensen...

Laten we het er gewoon op houden dat "De meningen verdeeld zijn, maar iedereen het er over eens is dat 'ECC helpt, maar niet een vereiste is om ZFS te draaien' ".


En om het weer terug on-topic te krijgen:



Zo jammer dat ASRock niet de moeite neemt om hun identifiers in te vullen

[ Voor 4% gewijzigd door DXaroth op 05-08-2014 15:59 ]

[FireDrunk]

Psst, die kan je bij een goede BMC zelf flashen

En het laatste wat ik eigenlijk over die hele ECC discussie wil zeggen is:

Wat heb je liever, dat we mensen MDADM en/of NTFS met ECC aanraden dan ZFS?
Nee, dan raden we dus altijd ZFS met ECC aan, tenzij mensen dat niet kunnen betalen...

Dan is een goede optie ZFS zonder ECC... Is het perfect? zeer zeker niet...
Is het extreem gevaarlijk dat ZFS corrupte data gaat weschrijven? Vast, maar die kans is niet kleiner bij NTFS en/of MDADM icm Ext4...

Dan zet ik persoonlijk liever mijn geld in op ZFS... Easy as that.

* FireDrunk heeft zelf ook gewoon een server met ECC geheugen gehad.. Heel lang zelfs... Maar ik besef me heel goed, dat ik eigenlijk alleen maar Films, Series, en ISO's op mijn bak heb staan, en als het stuk gaat, vloek ik wel een keer, maar daarna is het ook klaar.

Als ik echt een betrouwbare NAS zou willen, waar ik alle kiekjes van mijn kids (die ik niet heb) op zou willen zetten, ja, dan ga ik voor ECC...

[ Voor 90% gewijzigd door FireDrunk op 05-08-2014 16:25 ]

[Ultra]

FireDrunk schreef op dinsdag 05 augustus 2014 @ 16:19:
Als ik echt een betrouwbare NAS zou willen, waar ik alle kiekjes van mijn kids (die ik niet heb) op zou willen zetten, ja, dan ga ik voor ECC...

Beschrijf je nu niet precies de typische thuisgebruiker ?

[Q]

Laten we het er gewoon op houden dat "De meningen verdeeld zijn, maar iedereen het er over eens is dat 'ECC helpt, maar niet een vereiste is om ZFS te draaien' ".

Dat is geen goede formulering van het probleem. Een eerlijke formulering is dat ECC een reeel risico wegneemt, server systemen worden niet voor niets alleen maar met ECC geheugen verkocht. ZFS draaien zonder ECC geheugen is niet aan te raden, maar het werkt technisch gezien wel. Omdat ECC geheugen qua oplossing wat duurder is, kun je geld besparen. Dat je om niet-technische redenen (geld) kiest om het risico van geheugen fouten te accepteren is ieders goed recht.

[FireDrunk]

Die stelling vind ik te negatief. Dan zeg je dat ZFS een technisch niet goede optie is, en dat je dus beter voor iets anders kan kiezen.

Ik blijf er bij dat het een betere keuze blijft dan MDADM/Ext4 of NTFS zonder ECC.

[Paul]

Q schreef op dinsdag 05 augustus 2014 @ 16:35:
Een eerlijke formulering is dat ECC een reeel risico wegneemt

Er zijn wel meer dingen die reële risico's wegnemen, maar die worden hier niet zo heet bediscussieert als het ECC-vraagstuk Sterker nog, die komen amper aan bod...

Echter, je lijkt er ondertussen voor open te staan dat de wereld niet vergaat als je ZFS zonder ECC gebruikt, dus ik heb mijn doel bereikt

[Q]

Weer een onjuiste voorstelling van mijn positie, ik heb nooit beweerd dat de wereld vergaat als je geen ECC gebruikt. Overdrijven is ook een vak.

Ik ageer tegen de mensen die beweren dat het best acceptabel / OK is technisch gezien om ZFS zonder ECC ram te draaien en dat je zonder ECC ook wel veilig bent. Dat is niet waar. Dat mensen vanwege centen kiezen om toch geen ECC te draaien, is hun keuze, maar technisch gezien is het geen verstandige keuze.

Het is maar de vraag of je echt zoveel veiliger af bent met ZFS en zonder ECC tov legacy file systems als NTFS/XFS/EXT4 en zonder ECC. De legacy file systems maken minimaal gebruik van RAM naar mijn weten en zijn in feite veel minder gevoelig voor rot RAM en daar kun je er misschien nog mee weg komen. ZFS leunt juist enorm op het RAM en vormt dus juist een groter risico. ZFS beschermt dan wel tegen bit rot op disk, wat de legacy file systems niet doen. Maar je neemt aan de ene kant dan een risico weg maar aan de andere kant vergroot je een ander risico. En dat is een nuance die ik hier erg mis.

Het is ontstellend jammer als mensen dit soort teksten lezen:

Het verhaal dat je bij ZFS persé ECC geheugen moet gebruiken, is denk ik gewoon onzin. Het is een extra vorm van zekerheid, die je juist als je geen ZFS gebruikt extra hard nodig hebt. Gebruik je ZFS dan is de noodzaak voor ECC geheugen juist veel minder.

En vervolgens vrolijk hun data kwijt raken terwijl ze die paar tientjes extra gerust hadden willen betalen., als ze niet dit soort misinformatie hadden geloofd. Anderen hadden die tientjes niet willen betalen, ieder zijn keuze.

Maar laat mensen een eerlijke goed geïnformeerde keuze maken.

[ Voor 22% gewijzigd door Q op 05-08-2014 19:32 ]