Het grote DIY RAID NAS topic deel 3

[Verwijderd]

Slenger schreef op maandag 10 november 2014 @ 12:29:
Ik draai nu bijna een jaar de Netgear Readynas duo, puur om te proberen als een NAS mij bevalt.

Nu wil ik eigenlijk in december een NAS gaan bouwen, ik heb de volgende hardware uitgezocht :

Is dit voor een budget NAS een redelijke configuratie?

Je kunt ook kijken naar J1900/J2900 bordjes die zijn ook erg leuk voor een budget NAS. Hoeveel schijven wil je maximaal kunnen aansturen? Want er is bijvoorbeeld dit bordje: pricewatch: ASRock Q1900DC-ITX en die heeft een ingebouwde voeding. Dan heb je dus enkel een +12V voedingsblok nodig en geen grote ATX-voeding. Zuiniger en goedkoper. De voeding die je had uitgekozen is namelijk niet zo heel goed. Ga je echt veel schijven aansluiten dan wil je wel ATX hebben, maar tot 4 of 5 schijven zou prima kunnen en waarschijnlijk 6 ook. Dit bordje kan ook met +12V voedingsbrick werken. Ik heb hem zelf ook.

Verder zou ik je geheugen aanpassen; je hebt nu ouderwets 1,5volt CL11 geheugen en dat is eigenlijk de slechtste keuze. Dit is denk ik de beste keuze: pricewatch: Crucial Ballistix Sport BLS2C8G3D1609ES2LX0CEU. Maar gebruik anders de zoekfunctie van de pricewatch er zijn nog meer keuzes; alleen niet alle geheugenreepjes zijn in enkelvoud te krijgen; zoals dit setje gaat enkel per 2. Let erop dat je geheugen 1,35 volt is en DDR3/1600 met zo laag mogelijke CAS. Dat laatste is mooi meegenomen; CL8 is het beste, CL9 is goed, daarboven is casual. Natuurlijk luistert het niet zo nauw maar als het prijsverschil twee euro is zou ik gewoon gelijk goed geheugen nemen. Heel duur is bovenstaand setje bijvoorbeeld niet als je door twee deelt. En lekker veel RAM is altijd leuk voor een NAS.

Ook zit ik qua software nog te twijfelen tussen FreeNAS en ZFSGuru, nu wil ik eerst beiden in een VM proberen maar wat is voor iemand die een eerst NAS bouwt aan te raden?

FreeNAS heeft meer functies en meer volwassen, maar is ook wat ingewikkelder en heeft ook allerlei beperkingen die ZFSguru niet heeft. Zoals je SSD dat je daar het OS op kunt installeren en voor L2ARC kunt gebruiken enzo. Bij FreeNAS moet je dat allemaal gescheiden houden. Dat vind ik zelf niet zo fijn.

Voor uitgebreidere discussie over de ZFS platforms kun je het beste in het ZFS topic posten.

Ik heb in eerste instantie 2 HDD's van 2TB (WD RED). Deze wil ik in RAID 1 draaien.

Ik zou je WD Green aanraden. Als je dat doet wel even de headparking timer instellen op 300 seconden met WDIDLE.EXE een DOS utility. Zelf heb ik sinds kort de 6TB versie en daar ben ik erg over te spreken; is ook sneller dan de 4TB uitvoering met 175MB/s sequential read tegenover 150MB/s voor het 4TB model. En zuiniger omdat je met minder schijven toch een bepaalde capaciteit kunt behalen. Vooral als je voor dat Q1900 bordje gaat zou ik dit in overweging nemen.

DennusB schreef op maandag 10 november 2014 @ 12:43:
FreeNAS doen. Ontwikkeling van ZFSguru ligt stil!

Hoezo denk je dat? ZFSguru heeft nog nooit zoveel vorderingen gemaakt als afgelopen half jaar.

[Slenger]

Je kunt ook kijken naar J1900/J2900 bordjes die zijn ook erg leuk voor een budget NAS. Hoeveel schijven wil je maximaal kunnen aansturen? Want er is bijvoorbeeld dit bordje: pricewatch: ASRock Q1900DC-ITX en die heeft een ingebouwde voeding. Dan heb je dus enkel een +12V voedingsblok nodig en geen grote ATX-voeding. Zuiniger en goedkoper. De voeding die je had uitgekozen is namelijk niet zo heel goed. Ga je echt veel schijven aansluiten dan wil je wel ATX hebben, maar tot 4 of 5 schijven zou prima kunnen en waarschijnlijk 6 ook. Dit bordje kan ook met +12V voedingsbrick werken. Ik heb hem zelf ook.

Dit is een leuk bordje! Is de processor die erop zit wel snel genoeg? Ik heb nu namelijk dat de processor de snelheid van de NAS drukt.

Verder zou ik je geheugen aanpassen; je hebt nu ouderwets 1,5volt CL11 geheugen en dat is eigenlijk de slechtste keuze. Dit is denk ik de beste keuze: pricewatch: Crucial Ballistix Sport BLS2C8G3D1609ES2LX0CEU. Maar gebruik anders de zoekfunctie van de pricewatch er zijn nog meer keuzes; alleen niet alle geheugenreepjes zijn in enkelvoud te krijgen; zoals dit setje gaat enkel per 2. Let erop dat je geheugen 1,35 volt is en DDR3/1600 met zo laag mogelijke CAS. Dat laatste is mooi meegenomen; CL8 is het beste, CL9 is goed, daarboven is casual. Natuurlijk luistert het niet zo nauw maar als het prijsverschil twee euro is zou ik gewoon gelijk goed geheugen nemen. Heel duur is bovenstaand setje bijvoorbeeld niet als je door twee deelt. En lekker veel RAM is altijd leuk voor een NAS.

Is 16gb niet wat overkill? Ik zie dat er ook een 8gb variant is.
Of misschien dat deze wat is? :
pricewatch: Crucial BLT8G3D1608ET3LX0CEU

[Verwijderd]

Dat reepje is inderdaad ook erg goed; zelfs iets beter nog met CL8 ipv CL9. Eigenlijk het beste geheugen dat je kunt kopen; behalve overclocked geheugen wat ik nooit zou aanraden.

8GiB is ruim zat voor een budget NAS. De J1900 processor van Intel is ook single channel RAM dus een extra reepje levert geen snelheidsverbetering op. Dus jouw voorstel lijkt me prima.

Over de processor: de J1900 is een quadcore. Volgens mij ruim zat voor een simpele ZFS NAS. Jij zegt dat je processor niet snel genoeg is; welke processor is dat en welk OS/filesystem gebruik je en wat voor disk configuratie? Gebruik je compressie/encryptie of wat dan ook?

De langzaamste processor ooit; de C60 (AMD Brazos) dualcore op 1.0GHz kon nog wel bijna gigabit voltrekken met meerdere schijven in RAID-Z, maar dan liep hij wel op zijn tenen. Zaken als compressie en encryptie moet je dan niet gaan proberen. Maar de J1900 is flink sneller en ook quadcore, dus ik voorzie geen problemen voor een simpele NAS. Bovendien is het heel fijn dat hij passief gekoeld is; geen bewegende onderdelen dus voor de CPU en voor de voeding; dat heb je dan allemaal al passief gemaakt.

[Slenger]

Verwijderd schreef op maandag 10 november 2014 @ 19:02:

Over de processor: de J1900 is een quadcore. Volgens mij ruim zat voor een simpele ZFS NAS. Jij zegt dat je processor niet snel genoeg is; welke processor is dat en welk OS/filesystem gebruik je en wat voor disk configuratie? Gebruik je compressie/encryptie of wat dan ook?

Dat is de Netgear ReadyNAS Duo V2 gewoon alles verder standaard.

[Verwijderd]

Ja dat zijn allemaal ARM-chipjes toch? Dat is geen 'echte computer' mijns inziens maar ongeveer iets waar je telefoon op draait.

[Slenger]

Verwijderd schreef op maandag 10 november 2014 @ 19:17:
Ja dat zijn allemaal ARM-chipjes toch? Dat is geen 'echte computer' mijns inziens maar ongeveer iets waar je telefoon op draait.

Marvell® Armada 370 1.2GHz.


Ik vroeg mij alleen nog of welke kast ik erom heen zou doen, ik zag deze :
pricewatch: Cooler Master Elite 130

Maar hoe zorg ik ervoor dat ik de PSU gat dicht krijg zonder dat ik de halve case moet slopen?

Verder heb ik nu dit in mijn lijstje staan :

#	Product	Prijs	Subtotaal
1	ASRock Q1900DC-ITX	€ 95,32	€ 95,32
1	Crucial BLT8G3D1608ET3LX0CEU	€ 74,90	€ 74,90
1	Seasonic Power Adapter 60 Watt (12V)	€ 16,70	€ 16,70
1	Crucial MX100 128GB	€ 61,-	€ 61,-
Bekijk collectie Importeer producten		Totaal	€ 247,92

[GioStyle]

Een kleinere kast kopen?

[Slenger]

GioStyle schreef op maandag 10 november 2014 @ 20:11:
Een kleinere kast kopen?

Dit is al een HTPC kast voor Mini-ITX.

[GioStyle]

Je zou kunnen denken aan bijvoorbeeld dit:



Streacom F1CWS Evo Chassis

[Slenger]

GioStyle schreef op maandag 10 november 2014 @ 20:18:
Je zou kunnen denken aan bijvoorbeeld dit:

[afbeelding]

Streacom F1CWS Evo Chassis

Ik moet er minimaal 2x 3,5" en 1x 2,5" schijven inhebben, anders was dit inderdaad een heel leuk kastje geweest.

[ykp]

Maar hoe zorg ik ervoor dat ik de PSU gat dicht krijg zonder dat ik de halve case moet slopen?

Er zijn wel afdekplaten te koop, hier is een set van cooler master.

Is officieel wel voor een HAF stacker maar het lijkt mij dat die afdekplaat ook wel op een elite 130 gaat passen.

[Harrie]

Slenger schreef op maandag 10 november 2014 @ 20:19:
[...]


Ik moet er minimaal 2x 3,5" en 1x 2,5" schijven inhebben, anders was dit inderdaad een heel leuk kastje geweest.

Ik overweeg een build met deze case: pricewatch: Cooltek Coolcube Mini Zwart

Als je werkt met de externe voeding, kan je er met wat modden een hdd rack in maken. Dat heb ik gezien op een Duits forum. Volgens mij toch wel de kleinste kast waar nog wel een leuke NAS van te maken is.

Standaard ondersteunt hij 2x2.5" of 1x3.5". Maar zonder de voeding kan je vrij eenvoudig meerdere 3.5" boven elkaar plaatsen volgens mij.

Draadje op het Duitse forum: http://www.hardwareluxx.d...oolcube-mini-1024838.html
Je moet wel registreren om de foto's te bekijken..

[ Voor 24% gewijzigd door Harrie op 10-11-2014 21:47 ]

[Slenger]

ykp schreef op maandag 10 november 2014 @ 20:43:
[...]


Er zijn wel afdekplaten te koop, hier is een set van cooler master.

Is officieel wel voor een HAF stacker maar het lijkt mij dat die afdekplaat ook wel op een elite 130 gaat passen.

Dit is wel ideaal, iemand die kan bevestigen als hij echt past?

[The Lord]

Verwijderd schreef op zondag 09 november 2014 @ 15:33:


Wat heeft journaling hiermee te maken?
Wat bedoel je met 'schijf-virtualisatie software' ?
Wat heeft SSD caching hiermee te maken?

Zonder aangepast filesystem haal je sowieso niet het maximum uit een SMR-schijf; de problemen met random seeks nog niet meegerekend. Lees de paper eens die ik hierboven heb gepost; daarin wordt e.e.a. duidelijk gemaakt.

Het grote voordeel van een virtual disk is de scheiding tussen het volume met filesystem en de RAW disk. RAW disks gaan in een pool/group/aggregate, waar een virtual disk in wordt gecreëerd. Die virtual disk kan een standaard lay-out presenteren.

Nu zie je al dat 5400RPM consumer grade disks worden gebruikt voor hot data, omdat de latency van die disks er minder toe doet door journalling/caching/pointer table op een low latency opslag te plaatsen (SSD/specifieke caching layer).

Als de aansturing vanuit de pool/group/aggregate rekening houdt met RMW, dan is dit zonder meer toepasbaar voor hoofdzakelijk reads van data. En als de sizing van de journal/cache/pointer table voldoende is ook voor writes (enkel grote blokken sequentieel naar schone lokaties op de schijf).

Tapes werden tenslotte ook op deze wijze gebruikt, zij het in iets specifiekere omstandigheden.

[Verwijderd]

Het moment komt er aan ik heb weer wat geld. Voor een FreeNAS servertje met Plex die iets van 4 gelijktijdige streams aan moet kunnen waarvan max 3 fullHD; wat is de goedkoopste CPU uit onderstaande lijst die dat trekt met enige headroom? Ik heb gegoogled, maar het wordt mij niet duidelijker. Dus ik hoop op mensen die ervaring hebben hiermee. De quad cores hebben een hogere frequentie dus die trekken het zeker. Maar als de lager geklokte cores van de 6-core het ook trekken heb ik iets meer headroom om extra services te draaien in de toekomst.

#	Product	Prijs	Subtotaal
1	Intel Xeon E5-2603 V2 Boxed	€ 181,50	€ 181,50
1	Intel Xeon E5-2609 v2 Boxed	€ 257,73	€ 257,73
1	Intel Xeon E5-2620 v2 Boxed	€ 375,-	€ 375,-
Bekijk collectie Importeer producten		Totaal	€ 814,23

[GioStyle]

Transcoden of streamen? Streamen kan zelfs een G1610?

[Verwijderd]

GioStyle schreef op dinsdag 11 november 2014 @ 12:03:
Transcoden of streamen? Streamen kan zelfs een G1610?

Aargh, ik maak altijd zelfde fout. Een deel moet transcoded worden een deel gestreamt. Het gaat uiteraard om het transcoden, twee van de 'spelers' zijn PS3s via DLNA. Dan heb je een beperkt aantal ondersteunde codecs

[FireDrunk]

Dan zou een stevige i3 toch al redelijk voldoende moeten zijn denk ik? PLEX kan op de recente i3's toch gewoon op de GPU transcoden?

[Verwijderd]

FireDrunk schreef op dinsdag 11 november 2014 @ 12:16:
Dan zou een stevige i3 toch al redelijk voldoende moeten zijn denk ik? PLEX kan op de recente i3's toch gewoon op de GPU transcoden?

Geen idee waar mijn eerste reactie is gebleven ...

Anyway, ik heb al 64GB aan Registered ECC geheugen en gezien de gewenste betrouwbaarheid (hij gaat als off-site backup dienen voor meerdere mensen) ga ik alleen voor server hardware.

Verder is de GPU transcoding in Plex vrij beperkt.

[ Voor 5% gewijzigd door Verwijderd op 11-11-2014 12:58 ]

[br00ky]

Verwijderd schreef op dinsdag 11 november 2014 @ 12:22:
[...]

Geen idee waar mijn eerste reactie is gebleven ...

offtopic:
Je had er per ongeluk een topic report van gemaakt.

[FireDrunk]

Tja, als GPU transcoding een probleem is in PLEX , en je persé 3 * 1080p en 1*720p realtime wil transcoden, mag je inderdaad wel een dikke machine neerzetten...

Ik zou een hoog geclockte i7 nemen, daar helpt HT volgens mij.
Of als je echt genoeg power in huis wil halen, een Xeon E5 (socket 2011-3).

[Verwijderd]

FireDrunk schreef op dinsdag 11 november 2014 @ 15:21:
Tja, als GPU transcoding een probleem is in PLEX , en je persé 3 * 1080p en 1*720p realtime wil transcoden, mag je inderdaad wel een dikke machine neerzetten...

Ik zou een hoog geclockte i7 nemen, daar helpt HT volgens mij.
Of als je echt genoeg power in huis wil halen, een Xeon E5 (socket 2011-3).

3+1 is de theoretisch maximale belasting, realistisch is dat er max twee streams getranscode moeten worden en de rest gestreamt.

Een pricewatch: Intel Xeon E5-1620 Tray zou het ook moeten doen lijkt me? EN is niet al te prijzig.

[Verwijderd]

Die heeft geen ingebouwde videokaart (GPU) en kan dus volgens mij ook niet transcoden. Dergelijke CPUs worden gebruikt als er een IPMI en andere GPU op het moederbord is geïntegreerd.

[FireDrunk]

Trancoden kan ook gewoon op de CPU, dat is nou juist het probleem... De GPU Transcoding features van PLEX zijn maar mager, waardoor je eigenlijk wel een dikke CPU *moet* kopen...

[Verwijderd]

Dat is best.... dom...

De GPU kan zoiets juist veel efficiënter.

Nu moet je inderdaad met dikke cores gaan werken die flink moeten werken om te transcoden. Ook vermoed ik dat de kwaliteit van de videostream eronder kan lijden omdat bij CPU transcoding er een sneller algoritme met minder kwaliteit gebruikt zou kunnen worden. Maar dat is speculatie van mijn kant.

[Verwijderd]

De transcoder van plex gebruikt FFmpeg. FFmpeg gebruikt OpenCL voor, heel magere nog, hardware acceleratie. En verder ondersteunen ze nog een nvidia specifieke Unix API, maar dan ben je weer geld kwijt voor een GK, en met mijn eis aan de kwaliteiten wordt dat dan dus een Tesla oid worden, dan koop ik liever een dikke CPU, omdat die weer overkill is.

Overigens is de CPU transcoding van Plex juist weer erg goed!

[Wouter.S]

Mijn huidige nas is gebaseerd op een asrock B75 moederbord, een G530 en 16 GB niet-ECC geheugen. Er zijn twee volumes: 6x1.5TB Samsungs en 4x3TB Toshiba's in gebruik beide RAIDZ1, een losse 2.5inch opstartschijf en een 2TB scratch disk. Als uitbreiding voor sata-poorten is een IBM M1015 in gebruik.
Alles draait als een zonnetje onder zfsGuru (FreeBSD 9.1-RC1 0.2.0-beta7) De storage wordt hoofdzakelijk gebruikt voor media (films en series) en daarnaast allround opslag voor een 3-tal pc's. Het 4x3TB volume is er bijgekomen toen het eerste volume te klein werd. Echter zijn de volumes terug goed gevuld aan het raken, vandaar dat ik uitkijk naar waardige opvolger, stilstaan is immers achteruitgaan

Momenteel is er een offline backup bestaande uit oude disks, losse 1TB en 2TB schijven. Alles manueel, niet echt een luxe.

Het idee is om een volledig nieuwe nas te bouwen met één grote pool, en de bestaande nas als offline backup in te zetten. Waarbij de sync volledig automatisch, bijvoorbeeld wekelijks uitgevoerd wordt, zonder dat ik er wakker van moet liggen. Met de nieuwe nas wil ik liefst niet te veel compromissen maken, ik wil alles graag futureproof, compact en makkelijk te onderhouden en zo zuinig mogelijk. Niet de meest eenvoudige combinatie maar dit is de setup die ik momenteel in gedachten heb:

#	Product	Prijs	Subtotaal
1	Intel Celeron G1840 Boxed	€ 32,-	€ 32,-
1	ASRock E3C224D4I-14S	€ 223,20	€ 223,20
1	Lian Li PC-Q26	€ 150 ?	€ 150 ?
1	Crucial CT2KIT102472BD160B	€ 165,50	€ 165,50
5	WD Green WD60EZRX	€ 223,85	€ 1.119,25
1	Seasonic G-Serie 360Watt	€ 54,50	€ 54,50
Bekijk collectie Importeer producten		Totaal	€ 1.618,09

Cpu lekker goedkoop, moet gewoon kunnen streamen naar 3 clients en werkbaar blijven als op de achtergrond iets gedownload wordt. Het moederbord is misschien wat overkill maar in ieder geval futureproof, daarnaast ook leuke features met de kvm over ip chip. Ook niet meer klooien met een HBA kaart, alles is gewoon onboard. ECC-ram kost niet zoveel extra in toch een stuk veiliger. De case is een beetje een kruising tussen hot-swap en normale trays en je kan naar believen de backplane aanvullen als je meer disks hot-swap wilt. Ook een pak compacter dan een fulltower met 3 keer 4-in-3 modules. Voeding zo laag mogelijk vermogen, gold rating, degelijk materiaal.


Punten waar ik nog niet helemaal uit ben:

• Is raidz1 met 5 disks voldoende of is raidz2 met 6 disks toch meer aan te raden als je met dergelijke grote disks gaat werken. Wetende dat er een offline backup is, anderzijds kan je met ZFS natuurlijk niet eventjes een raidz1 omzetten naar raidz2...
• Ik heb nu voor WD greens gekozen, met het gedacht van als de disks twee jaar werken zullen ze waarschijnlijk 3 jaar ook wel halen. Dan is de garantie van de reds ook voorbij... mechanisch zijn de disks identiek alleen de firmware verschilt?
• Een ssd is waarschijnlijk niet nuttig voor voor mij doeleinden, het zou wel leuk zijn om wat mee te tweaken
• Geheugen is nu DDR1600, cas 11. Cas 9 zou beter zijn maar terug een stuk duurder, heeft dit een merkbare impact in de praktijk of zie je dit enkel terug in synthetische benchmarks?

Als jullie denken dat ik met deze setup ergens uit de bocht ga, shoot!

[FireDrunk]

Verwijderd schreef op dinsdag 11 november 2014 @ 16:12:
Dat is best.... dom...

De GPU kan zoiets juist veel efficiënter.

Nu moet je inderdaad met dikke cores gaan werken die flink moeten werken om te transcoden. Ook vermoed ik dat de kwaliteit van de videostream eronder kan lijden omdat bij CPU transcoding er een sneller algoritme met minder kwaliteit gebruikt zou kunnen worden. Maar dat is speculatie van mijn kant.

Tuurlijk, maar wat Plex niet wil, is voor elke GPU, van elke generatie, van elk merk uitzonderingen in zijn software bouwen (wat VLC / MPC-HC wel vaak doen, of beter gezegd, wat libavcodec en libffmpeg doen).

Ze willen hun software op een 'cleane' manier laten werken.

Best begrijpelijk. En bovendien ondersteunen niet alle drivers/videokaarten headless videoacceleratie. Sommige drivers werken gewoon direct richting de HDMI/DVI/VGA poort heb ik mij wel eens laten vertellen. Daardoor is Plex helemaal niet fatsoenlijk in staat op het gerenderde beeld weer goed op te vangen om door te sturen via LAN.

Bovendien is Plex niet zozeer degene die dit moet onderhouden, maar meer de GPU fabrikanten met hun drivers. En laten die nou juist niet zo'n haast maken...

Plex verwijten dat GPU acceleratie niet goed werkt icm bepaalde drivers, is een beetje als Windows verwijten dat je Game het niet goed doet... Soms kan het waar zijn, maar 99/100 keer ligt het ofwel aan je systeem (hardwarematig), ofwel de drivers.

[ Voor 9% gewijzigd door FireDrunk op 11-11-2014 19:13 ]

[Verwijderd]

Wouter.S schreef op dinsdag 11 november 2014 @ 19:09:
Het idee is om een volledig nieuwe nas te bouwen met één grote pool, en de bestaande nas als offline backup in te zetten. [..] Met de nieuwe nas wil ik liefst niet te veel compromissen maken, ik wil alles graag futureproof, compact en makkelijk te onderhouden en zo zuinig mogelijk. Niet de meest eenvoudige combinatie maar dit is de setup die ik momenteel in gedachten heb:

Leuk bordje; de eerste keer dat ik zie dat de chipset SATA deels via Mini-SAS wordt aangeboden; vandaar de drie keer Mini-SAS connectors voor in totaal 12 SATA disks. En dan apart nog 2x SATA/600 van de chipset voor SSD/boot enzo. Leuk!

Maar je hebt het over RAID-Z met 5 disks. Dat vind ik niet stoere configuratie voor zo'n dure build. Ik zou je aanraden voor RAID-Z2 te kiezen. 10 disks in RAID-Z2 is eigenlijk de beste configuratie. Wat je wel kunt doen is een RAID-Z2 maken met één disk minder; dan draai je single degraded. Dan kun je later nog een extra disk kopen om er een RAID-Z2 van te maken. Maar zelf zou ik gewoon direct alle disks tegelijk kopen. De vraag is alleen of 10 disks in één keer wel binnen je budget past. Het alternatief is twee setjes van 6 disks in RAID-Z2. Dat past ook binnen je 12x SATA via Mini-SAS en daarnaast 2x SATA voor boot/OS/cache. Maar dan zit je met in totaal 4 parity disks. De configuratie van 10 disks in RAID-Z2 vind ik de sweet spot voor home NAS.

WD Green is denk ik de beste keus. Zorg wel dat je WDIDLE.EXE uitvoert zodat je de headparking timer naar 300 seconden kunt instellen. Dit moet je doen op de chipset SATA; kan denk ik niet via de SAS controller.

CAS9 is voor non-ECC UDIMM helemaal niet duurder dan ouderwets CAS11 geheugen. Maar als het prijsverschil voor ECC UDIMM wel redelijk groot is, kun je denk ik prima voor CAS11 gaan. Wel speculeer ik dat ZFS doordat het zo geheugenintensief is ook bovengemiddeld veel profijt heeft van sneller RAM geheugen; maar ik heb hier nooit zelf testjes mee gedaan.

[FireDrunk]

Ik heb wel eens getest of mijn Celeron G1610 (1333Mhz geheugen) langzamer was dan mijn i5-3570 (1600Mhz geheugen). Nooit iets van gemerkt. (niet doorslaggevend natuurlijk, maar just sayin')

[Verwijderd]

Denk dat het pas echt gaat tellen als je 10G+ ethernet gaat gebruiken, en met grote pools gaat werken.
Maar lokaal zou je het wel kunnen uittesten, met simpele benchmarks. Dus een keer een testje zou kunnen, bijvoorbeeld door je DDR3/1600 geheugen op 800MHz in te stellen. Kijken of dat effect heeft. Punt is wel dat dan ook vaak de latencies omlaag gaan; dus dat compenseert dan weer deels.

[FireDrunk]

Mja, dannog denk ik niet dat ZFS echt het probleem zal zijn, 10Gb is (behalve icm netmap) van zichzelf al veeeeeel zwaarder voor je CPU

Maar wat je zegt klopt zeker, het zou het testen misschien wel waard zijn, maar ach. Als je kijkt in bijvoorbeeld Memtest, dan zie je vaak al snelheden van meerdere GB/s per seconde...

Niet echt veel mensen hier die daar echt 'last' van hebben

[Verwijderd]

Ja maar daar maak je de fout door te denken dat als je RAM 10GB/s is, je streams dat ook zijn. Wat ZFS doet is veel memory copies en splits, dus je kunt het gemakkelijk door 4 of door 8 delen; heel simpel gezegd. Althans die ervaring heb ik met profiling van de RAID5 driver van FreeBSD. De hoeveelheid memory combine & splits zorgt voor heel geheugenintensieve operaties waarbij de snelheid afhangt van de latency van het RAM geheugen, mits de data snel genoeg kan worden aangeleverd. Het lijkt me daarom zeer aannemelijk dat ZFS ook schaalt met RAM performance vooral zodra je disks snel genoeg zijn.

Zo heb ik de wens om zodra er een 1TB opvolger is van de MX100, een vijftal SSDs te kopen voor mijn 24/7 storage. Met vijf van die SSDs die met SATA toch 2,5GB/s kunnen doen en met PCIe nog veel meer, dan kom je wel aan de grenzen van de rest van je hardware. En ik speculeer daarbij dat het niet zozeer FPU/ALU performance bottlenecks zullen zijn (je CPU) maar wel RAM bottlenecks. En dat een lagere latency daarbij kan helpen.

In veel RAM benchmarks zie je dat het verschil tussen traag en snel RAM maar een paar procent is. Maar bijvoorbeeld voor de onboard GPU bij AMD zag je dat er 100% performance verschil kan zijn (2x zo snel) tussen traag en snel geheugen. Dus iets wat zeer sterk op geheugen latency/throughput leunt kan wel degelijk een groot effect hebben op de keuze van het geheugen. Ik speculeer dus dat dit deels ook voor ZFS geldt.

[player-x]

Verwijderd schreef op woensdag 12 november 2014 @ 15:10:
Denk dat het pas echt gaat tellen als je 10G+ ethernet gaat gebruiken

Het is trouwens niet zo moeilijk (lees duur) meer om een 10G+ verbinding op te zetten.

Heb nu 5m lange Thunderbolt verbinding tussen mijn Game-PC en Server, en haal nu met grote files 6 tot 900MB/s, een behoorlijke verbetering over Gbit.

Koste me alleen wel wat bier en een maaltijd om het op te zetten, want zelfs netwerk geeks krijg je niet aan het werk op alleen kraan water, en hoewel ik geen netwerk n00b ben is het opzetten van routingstabellen op een 2012R2 server is net te hoog gegrepen, of beter gezegd iets waar ik me niet in wil verdiepen.

Heb ook Belkin Thunderbolt Dock besteld en ga kijken of ik die ook als Thunderbolt netwerk brug kan gebruiken, en er twee PCs rechtstreeks op kan aansluiten, en de dock ook een verbinding naar de rest van traditionele netwerk laten leggen.

CPU snelheid kan dus best snel relevant worden.

[Verwijderd]

Ik had gehoord dat de nieuwe Thunderbolt-standaard een native implementatie heeft van een point-to-point ethernet interface. Net als Firewire (fwe) kan het dan ook standaard in FreeBSD geïmplementeerd worden en als je thunderbolt hebt is het zo simpel als een kabel inpluggen en je hebt een werkende point-to-point netwerk interface. Met 20Gbps heb je dan ook echt een leuke hoeveelheid bandbreedte om een stoere ZFS NAS op te tuigen voor thuis.

[FireDrunk]

Thunderbolt is idd wel geniaal... Ik zie er naar uit!

[player-x]

Verwijderd schreef op woensdag 12 november 2014 @ 17:29:
Met 20Gbps heb je dan ook echt een leuke hoeveelheid bandbreedte

TB2 kan je voorlopig nog wel vergeten, de borden daar voor beginnen met ruim 200 euro, een ASUS TB2 kaartje is nog wel betaalbaar, maar moest ik in de US bestellen voor $70.

Maar kan voor nu prima leven met de 10Gbit dat ik nu EINDELIJK heb, want ik vind mijn Asus Z87-Expert C2-stepping + i7-4790K al aardig overkill, voor een server bord.

Doe al mijn video encoding op mijn server, en dat gaat het snelste op een i7 CPU, daarnaast wil ik de CPU en mobo kunnen hergebruiken, net zo als de oude 2600K, die nu samen met een GTX 9800, de basis is van mijn dochters PC.

[Verwijderd]

TB3 komt volgend jaar als feature van Intel Skylake. Gepland voor eind 2015. 40Gbps bandbreedte en energiebesparingen. Verwacht ook wel dat het betaalbaar zal zijn. Als je ziet hoeveel je nu betaalt voor een casual 10GBaseT NIC en wat je straks betaalt voor 40Gbps wat al gewoon op het moederbord zit, lijkt me dat een fantastische prijs/prestatie-verhouding.

[player-x]

Ja ik weet het, maar kon gewoon niet langer Gbit verdragen, en TB1 lost dat nu al op, want heb nog niet meer dan 10Gbit nodig.

De keuze voor TB was simpel als je naar de prijs van een Intel X540-T1 10Gbit kaartje kijkt.

En verwacht jij dat je met een HDD array echt boven de 10Gbit uit zal komen, mijn 17 disk R6 ntfs array kom al niet boven de 10Gbit, want de ZFS array's die geen OCE ondersteund zullen nog minder waarschijnlijk daar boven uit komen.

[Verwijderd]

Oh jawel; de RAM cache (ARC) doet zijn werk heel goed en is bij ZFS slimmer dan bij ouderwetse VFS-implementaties. Kortom, als je een dikke ZFS server bouwt met lekker veel RAM, kun je extreem goed schalen bij 40Gbps Thunderbolt; laat staan een trunk van 2x40Gbps Thunderbolt. Zo rek je de performance caps wel op tot de limiet van je CPU+RAM subsystem. Met name RAM zal de bottleneck worden is mijn veronderstelling.

Met een SSD pool zoals ik hierboven voorstelde kun je ook al gemakkelijk tot ~2GB/s read komen. Maar er zijn ook genoeg HDD pools waarbij je tegen de 1GB/s read/write kunt halen. Kortom, de gigabit cap gaat geslecht worden voor thuisgebruikers die wel wat extra willen betalen, maar niet voor die overprices 10GBaseT-hardware zoals de X540 die je noemt. Ik had de hoop dat die NIC snel goedkoper zal worden maar dat blijkt achteraf niet het geval. Thunderbolt is het volgende waar ik me op richt.

Punt is wel dat het in BSD ook nog geïmplementeerd moet worden. Echter, BSD developers houden van goede documentatie en Intel staat er wel om bekend om die te leveren. Kortom, ik zie het wel gebeuren. De vraag is wanneer, hoe goed en voor welke prijs.

[FireDrunk]

Grappig is natuurlijk wel... ARC is RAM. Bij een dikke thuis server praten we over 32GB RAM.
Als daarvan 30GB voor ARC is, heb je dus in *tromgeroffel* 10 seconden je hele ARC ingelezen... (in het geval van 20/40Gb TB)

Super nuttig!!!

ARC en >10Gb is een beetje... meh... Het wordt juist pas leuk als je het over meerdere TB's aan data verplaatsen hebt.

[ Voor 4% gewijzigd door FireDrunk op 12-11-2014 19:44 ]

[Verwijderd]

Voor bulkdata is ARC ook niet nuttig. Maar vooral voor veelgevraagde data.

Zo denk ik bijvoorbeeld om alle desktop clients zonder HDD/SSD te voorzien, maar centraal alles op de ZFS server te houden via PXE netboot. Zo'n setup had ik ooit al, en werkt redelijk goed. Ook vrij snel; ik heb nog wat Ubuntu benches met latency. De (random seek) latency was met gigabit nog twee keer zo hoog als een lokale SSD; maar dat is nog steeds erg goed!

20/40Gbps is natuurlijk een beetje overkill voor thuis. Maar jij noemt bulkdata. Als je twee ZFS servers hebt waarbij de ene de andere mirrort, en je 's nachts gaat syncen, ik noem maar wat, dan kan die bandbreedte wel van pas komen.

Pas als je iets hebt, kun je het benutten en ontstaan er nieuwe mogelijkheden van snelle datauitwisseling. Het is ook vreemd en onnodig dat de interface de bottleneck is; de kabel hoort niet de beperkende factor te zijn maar de disks zelf. Het is dus normaal dat je interface minimaal 2x sneller is dan je disks data kunnen aanleveren. Dat we al die tijd op gigabit hebben geleefd wil niet zeggen dat dit technisch gezien een normale situatie is. Netwerkbandbreedte heeft gewoon weinig vooruitgang gekend voor thuisgebruikers/powerusers. Dat heeft allerlei redenen; maar vooral voor ons ZFS gebruikers is het wel jammer dat je je pool performance van 500-800MB/s gemiddeld niet effectief kunt benutten.

[Paul]

Nou ja, je hebt ook (bijvoorbeeld) 6 schijven, neem dan ook 6 touwtjes om het eerlijk te houden Dan loopt gigabit nog steeds achter (zeker als je SSD's neemt) maar aan de ene kant alle krachten bundelen en dan verwachten dat de eenzame strijder het wel bij zal houden is niet helemaal fair

[Verwijderd]

Ik volg je niet helemaal; eenzame strijder het bij moeten houden?

[Paul]

Je neemt de gecombineerde doorvoersnelheid van een X aantal schijven en dat pers je door één netwerkkabel. Vind je het dan gek dat die netwerkkabel het niet bij kan houden?

Een HDD doet ~100 MB/sec (sequential), een gigabitverbinding ook. Als je maar voldoende schijven neemt dan loopt de verbinding vanzelf vol.

[player-x]

Verwijderd schreef op woensdag 12 november 2014 @ 19:10:
Met een SSD pool zoals ik hierboven voorstelde kun je ook al gemakkelijk tot ~2GB/s read komen.

Maar wie gaat er nu een SSD pool maken op zijn server, anders dan voor bedrijfssystemen?

Als ik een SSD pool ga maken, dan doe ik dat op mijn hoofdmachine, en ik ga echt niet onnodig data over pompen over het netwerk, ik wil geen HDDs in mijn machine, maar SSDs heb ik niet echt een probleem mee.

Gebruik nu al een SSD R0 (2x 1TB EVO) array voor het opslaan van mijn RAMdisk ''images'', in RAR formaat die ik dan uitpak op de RAMdisk, wat me zelfs nog beter dan verwacht bevalt.

Wat ik nog wel iemand zie doen is bv twee oudere -256GB SSDs als HDD cache gebruiken, maar dan houd het denk ik toch wel op.

En dan nog zit je voorlopig nog wel goed met TB1, uiteraard zeg ik niet dat TB2 of TB3 niet beter zijn, maar voorlopig zit je vooral met prijs technische redenen om het nog niet te kiezen, en is voorlopig TB1 nog steeds snel genoeg, iig voor mijn gebruik, hoewel mijn GamePC al TB2 heeft, was het me niet de extra +100 euro waard om op mijn server nu ook al TB2 te nemen.

Het is iig net zo een verademing als 10Mbit > 100Mbit en 100Mbit naar 1Gbit, en toen hadden we bergen mensen die Gbit overdreven vonden. LOL

[ Voor 4% gewijzigd door player-x op 12-11-2014 20:48 ]

[IceTeaGX]

Mja, NIC teaming heeft niet veel nut op een point-to-point verbinding.

En niet elke thuisgebruiker heeft gelijke verwachtingen.
Voor remote storage voor een ESX server bv kan een SSD pool zeer handig zijn.
En ja, sommige mensen hebben dat thuis staan.

[Verwijderd]

Maar wie gaat er nu een SSD pool maken op zijn server, anders dan voor bedrijfssystemen?

Ehm, ik?

Zodra SSDs voor massaopslag betaalbaar worden, ben ik over hoor. En ik denk met mij vele anderen. Alleen grootverbruikers van bulkopslag zoals cloudproviders e.d. zullen nog lang op mechanische techniek leunen, maar de massa zal op een gegeven moment over gaan. Dat zal al veel eerder het geval zijn dan de 1:1 prijs per gigabyte verhouding geslecht zal worden.

Nu al zijn er vele computers die geen HDD meer hebben; enkel solid state storage. Met goedkope 1TB SSDs in het vooruitzicht zal de threshold - het omslagpunt - niet lang meer duren. Dan is het ook aannemelijk dat de markt voor mechanische opslag het zwaar te verduren krijgt en dat betekent dat mechanische opslag nog trager zal innoveren, terwijl solid state storage in rap tempo vorderingen maakt. Vanaf dat omslagpunt, is het in feite afgelopen met mechanische opslag, zo heb ik reeds jaren geleden voorspeld.

Mja, NIC teaming heeft niet veel nut op een point-to-point verbinding.

Dat is niet waar; enkel LACP heeft daarbij geen nut. Voor round robin heeft dit wel nut en kun je een enkele TCP stream accelereren met link aggregation.

[player-x]

Verwijderd schreef op woensdag 12 november 2014 @ 20:58:
Dat zal al veel eerder het geval zijn dan de 1:1 prijs per gigabyte verhouding geslecht zal worden.

Dat betwijfel ik, de twee tientjes dat een RED meer kost dan een Green is voor veel mensen al een te grote stap, en de prijs is nu nog steeds 1:10, en ik denk dat we op zijn minst nog 5 maar eerder 10 jaar weg zijn voor dat de prijs onder de 1:2 zakt.

Roest is gewoon een heel stuk goedkoper dan silicon om mee te werken.

Kleine array's van minder dat 6~8TB kan ik nog wel zien, voor een enkeling, maar dat is meer een uitzondering, boven op de mensen die al een uitzondering zijn met het hebben van een thuis server.

Vanaf dat omslagpunt, is het in feite afgelopen met mechanische opslag, zo heb ik reeds jaren geleden voorspeld.

Voor bulk opslag van bv video data zie ik iig voorlopig nog geen eindpunt in zicht, zo als de omslag van analoog naar digitaal als bij Kodak.

Dat is niet waar; enkel LACP heeft daarbij geen nut. Voor round robin heeft dit wel nut en kun je een enkele TCP stream accelereren met link aggregation.

Maar nog steeds niet optimaal ten opzichte van een hogere doorvoer van een enkele verbinding.

Op mijn netwerk iig geen link aggregation stoelen dans.

[IceTeaGX]

Verwijderd schreef op woensdag 12 november 2014 @ 20:58:Dat is niet waar; enkel LACP heeft daarbij geen nut. Voor round robin heeft dit wel nut en kun je een enkele TCP stream accelereren met link aggregation.

Onder VMware is dat wat lastiger zeker.
Niet dat ik het echt nodig heb, heb (nog) geen destination met dual nics.
Dus spreiding van verschillende streams is al goed genoeg.

[Verwijderd]

Round Robin is een schending van de TCP specificatie dus vele switches kunnen niet omgaan met Round Robin. Sommige wel; en als je direct aansluit ('crosslink') dan werkt het ook. Maar ik heb enkel ervaring met BSD <--> BSD. Linux moet ook werken; of het met Windows werkt betwijfel ik. LACP is veel beter ondersteund; maar juist dat heeft geen nut voor single TCP stream performance. En dat is juist wat we willen. Ik geloof wel dat nieuwe versies van CIFS met multipath TCP streams werken en dan zou LACP wel nut kunnen hebben.

Hoe dan ook; Thunderbolt is de volgende stap in home NAS networking waarbij je de 10GBaseT stap geheel kunt overslaan omdat die nooit echt is doorgebroken. Veels te duur; geen concurrentie. Pas als er $10 chipjes van Realtek komen, komt er een doorbraak op dat gebied. En dat is niet gebeurd, terwijl dat wel bij gigabit gebeurde. Vandaar dat 10GBaseT nooit is doorgebroken; en vele het zullen overslaan.

[player-x]

Verwijderd schreef op woensdag 12 november 2014 @ 22:14:
Pas als er $10 chipjes van Realtek komen

Of in de chipset verwerkt word.

Ik hoop dat er snel netwerk switches komen met iig twee TB uplink poorten, dat zou het bouwen van een snel netwerk een heel stuk, gemakkelijker maken, maar ik denk dat we moeten wachten totdat er NASsen op de markt komen met een TB aansluiting.

[Emcee]

Ga een simpel nasje bouwen van een pc die er toch staat met de volgende specs:
Mobo: Gigabyte ma785gt-ud3h AM3
Cpu: Amd dual core x2-240 socket AM3 2,8GHz
Cpu cooler: Coolermaster hyper Z600
Memory: 6 GB ddr3
Power: Cooler Master real power 450W
Case: Cooler Master Gladiator 600

Wil er 6x4TB WD Green in doen, en dan met ZFS een RaidZ2 maken voor een netto opslag van 16TB

Wordt een simpele server, die ik vooral wil om backups van data op te maken en te bewaren.
En ook om een beetje te leren omgaan met ZFS, kijken of het bevalt. Ook in deze vrij eenvoudige setup zonder ZIL of L2ARC op een SSD, hoop wel dat ik hiermee gigabit netwerkverbinding snelheden ga halen dan is het wat mij betreft prima.
(Zit al te denken aan een serieuzere setup tzt met geschiktere componenten en ECC geheugen maar dat is voor de toekomst.)

Gezien de bovenstaande specs en de beperkte hoeveelheid geheugen wat voor snelheden zou ik mogen verwachten over het netwerk? Mobo heeft wel realtek netwerkchip, misschien toch een extra intel netwerkkaart er in doen?

[TrsvK]

Ik heb gisteren mijn greens op de post gedaan aangezien deze na 3 maanden al op 150.000 load cycles zaten. Ik las dat er voor RED drives een firmware update is gekomen die dit probleem (head parking) zou tegengaan. Hoe hebben jullie dit aangepakt?

Ik ben nu bezig met het samenstellen van een workstation die snel met de nas zou moeten communiceren. Mijn NASmobo en switch ondersteunen beiden LACP. Als ik nu een nieuw moederbord uitzoek voor mijn workstation met een Intel NIC en er een losse netwerkkaart bij prik, kan ik deze dan bonden en snellere doorvoersnelheden behalen? (FreeNas-Windows)

[Verwijderd]

@TrsvK: dan heb je nog niet gelezen wat veel herhaald wordt: als je de Greens 24/7 gebruikt dien je WDIDLE.EXE uit te voeren op de schijven zodat je de headparking timer op 300 seconden instelt. WD Red heeft headparking helemaal uitgeschakeld en dat is erg jammer omdat deze hierdoor minder zuinig zijn en ook meer gevoelig voor schokken. Headparking is een nuttige feature, alleen moet je deze minder agressief instellen.

De Greens zijn specced op 300.000 load cycles, maar een schijf met een miljoen cycles kom ik niet zelden tegen en die doen het gewoon. Maar het kan wel zorgen voor meer slijtage en dus mogelijk een hogere kans op falen. Ook kan het responstijd negatief beïnvloeden. Door het instellen op 300 seconden heb je de beste werelden van beide; de Greens zijn dus beter dan de Reds mijns inziens.

Over LACP; je hebt niet dezelfde NICs nodig hiervoor. Je kunt ook verschillende merken NICs bonden. Intel biedt Windows drivers met link aggregation ondersteuning; een feature die Windows niet van zichzelf biedt. Je hebt dus eigenlijk enkel Intel NICs nodig voor Windows; niet voor BSD/Linux om te bonden.

[TrsvK]

Ja, had WDIDLE gevonden maar toen was mijn count al hoog geworden. Als ik mijn nieuwe schijven binnen heb zal ik ze direct "preppen". Mijn FreeNas bak heeft al LACP ingeschakeld en mijn switch ook, nu dus alleen de nieuwe windows kast nog. Ik wil een moederbord kopen met een Intel NIC en er dan een pricewatch: Intel Gigabit CT Desktop Adapter bijprikken. Gaat dat werken om een 2Gb connectie op te zetten? Kan ik dan ook sneller bestanden van en naar mijn NAS kopieren? Ik heb begrepen dat dit niet werkt met 1 bestand maar wellicht wel als ik een map vol bestanden overzet??

[FireDrunk]

Nee, consumenten NIC's ondersteunen dat helemaal niet voor zover ik weet blijkbaar kan die CT het wel (http://www.intel.com/cont...t-ct-desktop-adapter.html), bovendien moet je switch het ook ondersteunen. LACP is een proprietary protocol wat door je Switch ondersteund moet worden. (Cisco noemt het geloof ik EtherChannel, en andere merken gebruiken wat vaker de term LACP, of 802.3ad.)

http://en.wikipedia.org/wiki/Link_aggregation

Er zijn veel caveats als het gaat om Link Aggregation, en als je hoopt op 'gewoon' een 2Gb connectie, zul je snel van een koude kermis thuiskomen... Zo kan je niet (zomaar) 1*1Gb pairen tot 2Gb als het gaat om point-to-point verbindingen... Je kan onder Linux (en volgens mij ook BSD) vieze dingen doen als Round Robin, maar dat is buiten de internationale specs volgens mij, waardoor veel andere Operating Systems (waaronder Windows ) het niet ondersteunt.

Als je echt meer dan 1Gb wil, ga dan gewoon voor 10Gb... Dat is een stuk makkelijker qua configuratie, alleen een stuk duurder, en een 10Gb switch is vrijwel onbetaalbaar

[ Voor 7% gewijzigd door FireDrunk op 13-11-2014 08:22 ]

[TrsvK]

Ja dat is mijn probleem

Consumenten NICs ondersteunen trouwens wel LACP (http://www.intel.com/support/network/sb/cs-009747.htm) en mijn switch en nas ook. Het is sowieso wel prettig dat mijn NAS nu 2 users een Gb verbinding kan geven maar het zou een leuke toevoeging zijn als deze doorvoer ook naar 1 user kon worden geleid.

Wellicht een hele stomme vraag maar: "wat gebeurd er wanneer ik twee copy paste commandos tegelijk zou uitvoeren op 1 pc die dmv LACP verbonden is met een NAS?"

[A1AD]

TrsvK schreef op donderdag 13 november 2014 @ 09:04:
Wellicht een hele stomme vraag maar: "wat gebeurd er wanneer ik twee copy paste commandos tegelijk zou uitvoeren op 1 pc die dmv LACP verbonden is met een NAS?"

_{Uw lokale harde schijf dat niet kan volgen}

[VorCha]

TrsvK schreef op donderdag 13 november 2014 @ 09:04:
Wellicht een hele stomme vraag maar: "wat gebeurd er wanneer ik twee copy paste commandos tegelijk zou uitvoeren op 1 pc die dmv LACP verbonden is met een NAS?"

Dan wordt voor elke copy pasta actie, een link gebruikt. LACP is meer een load balancer concept dan dat het bandwidth stapeling is. De maximale snelheid per acties is nog steeds 1Gbps, maar het kan dat wel 2 x faciliteren. Dus beide copy pasta's zouden in theorie 1Gbps kunnen halen. Ware het niet dat 1 lokale schijf snelheid nog niet eens 1Gbps volledig kan benutten. Maar memory-to-memory zou resulteren in snelheden tegen de 1Gbps aan, niet 2Gbps.

[FireDrunk]

Volgens mij werkt LACP op een hash van Source en Destination IP adres, en zullen twee copy paste commando's dus niet resulteren in een verhoogde saturatie van de trunk

(Je kan met alternatieven wel een round robin hash instellen op basis van TCP/UDP poort, maar dan moet de software voor elke copy actie wel een andere TCP/UDP poort gebruiken, en niet alle software doet dat.)

(Als je wil zoeken of je switch het ondersteund, het heet L4 Hashing (TCP/UDP is ISO laag 4)
Bedenk wel: Dat zijn volgens mij features die je alleen krijgt in de wat pittiger geprijsde modellen (Nexus 5000 enzo...)

pricewatch: Cisco Nexus 5010

Zoiets

@CiPHER: Overigens, wat jij zegt over Windows is ook niet (meer) waar.

http://en.wikipedia.org/w...egation#Microsoft_Windows

Microsoft Windows does support native link aggregation starting from Windows Server 2012.

[ Voor 44% gewijzigd door FireDrunk op 13-11-2014 10:41 ]

[Verwijderd]

Goed om te weten; maar ik vermoed geen round robin, maar eerder LACP? Voor ons is LACP niet zo heel interessant. Windows server die veel connecties maakt met lokale servers zoals SQL enzovoorts, dan kan het wel nut hebben. Of als failover; dat vergeten wij thuispiepers nogal eens.

[Q]

LACP is relevant voor failover en servers met veel verschillende clients, maar totaal nutteloos voor 1-op-1 verbindingen. Linux Round-robin werkt als een malle, maar alleen tussen Linux machines, zie link in mijn signature.

Als je voorbij de 1 Gbit wilt met 2 machines, dan kost het je 2x10gbit netwerk kaarten. Een 10Gbit switch kost je 800+ euro.

Ik vraag me af of je nu al via USB3 over IP kunt doen en hoe het staat met thunderbolt.

[ Voor 3% gewijzigd door Q op 13-11-2014 12:00 ]

[Nindustries]

En we mogen natuurlijk niet vergeten dat dit allemaal wel mogelijk is indien we enkel over iSCSI praten.

[player-x]

Q schreef op donderdag 13 november 2014 @ 12:00:
Ik vraag me af of je nu al via USB3 over IP kunt doen en hoe het staat met thunderbolt.

TB werkt prima voor nu voor mijn, gebruik een oude truck, die ik voor heen gebruikte toen we onboard Gbit NICs kregen, maar switches nog steeds onbetaalbaar waren.



Ben bezig met een TB dock te bestellen, met twee TB aansluitingen, en ga kijken of ik die als brug naar de rest van het netwerk kan gebruiken.



Ben benieuwd of dit ook daadwerkelijk mogelijk is.

[FireDrunk]

En SMB Multichannel is ook zo'n mooie techniek

http://blogs.technet.com/...ver-2012-and-smb-3-0.aspx

[Nindustries]

FireDrunk schreef op donderdag 13 november 2014 @ 12:18:
En SMB Multichannel is ook zo'n mooie techniek

http://blogs.technet.com/...ver-2012-and-smb-3-0.aspx

Als linux/BSD/<vulhierin> dat nu ook eens ondersteunde was iedereen goed af..

[FireDrunk]

https://wiki.samba.org/index.php/SMB3#Multi_Channel

https://git.samba.org/?p=...ads/master3-multi-channel

Ze zijn er lang mee bezig hoor

[MTDjassen]

TrsvK schreef op donderdag 13 november 2014 @ 07:53:
Ja, had WDIDLE gevonden maar toen was mijn count al hoog geworden.

Om hierop in te haken, ik heb een 24/7 FreeNAS systeempje runnend met 3*2TB WD Greens (WD20EZRX). Nadat ik dit las ben ik geschrokken, snel load cycles gaan checken en ja hoor. Die staan na 3 maanden in gebruik alledrie rond de 130.000. Wat zouden jullie aanraden? Terugsturen (wat echt een hassle is want ik heb geen directe media beschikbaar om al m'n data op over te zetten) of nu nog WDIDLE runnen en hopen op het beste?

- Edit: tevens, in freenas kun je ook de HHD Standby tijd veranderen, ik neem aan dat dit fundamenteel anders is dan WDIDLE runnen (higher level?) en dus minder effectief?

[ Voor 12% gewijzigd door MTDjassen op 13-11-2014 12:55 ]

[FireDrunk]

CiPHER roept vaak dat die dingen 300.000 load cycles aan kunnen, dus je kan met WDIDLE de timer op 60s zetten ipv 30s, dan gaan je schijven iets minder in 'standby' maar slijten ze dus ook wat minder...

Je kan ook head parking gewoon uitzetten als je echt bang voor slijtage bent... (timeout=0)

[Verwijderd]

300.000 staat in de spec sheet. Maar ik kom regelmatig disks tegen die een miljoen of zelfs bijna twee miljoen load cycles hebben. Dus niet gelijk panieken: als je er nu snel bij bent dan is het prima. Gewoon WDIDLE gebruiken en je load cycles zullen niet meer zo snel stijgen.

[MTDjassen]

*MTDJassen legt even een HDMI kabel van 10 meter door z'n huis heen omdat hij een scherm nodig heeft.

[FireDrunk]

Hahaha, waarom niet gewoon de monitor oppakken?

[MTDjassen]

De monitor is m'n TV die met beugel aan de muur hangt ;-)

-overigens: nog een specifieke versie van WDIDLE? Op de supportpage van de WD20EZRX staat hij niet...

[ Voor 63% gewijzigd door MTDjassen op 13-11-2014 13:15 ]

[Verwijderd]

FireDrunk schreef op donderdag 13 november 2014 @ 12:58:
CiPHER roept vaak dat die dingen 300.000 load cycles aan kunnen, dus je kan met WDIDLE de timer op 60s zetten ipv 30s, dan gaan je schijven iets minder in 'standby' maar slijten ze dus ook wat minder...

Je kan ook head parking gewoon uitzetten als je echt bang voor slijtage bent... (timeout=0)

Ik heb 5 x 2TB greens, waarvan één uit een oudere serie. Die oude kon ik timeout=0 op instellen, die nieuwe accepteerden dat niet meer!

[FireDrunk]

Dan zet je hem heel hoog: 65536 ofzo Dat is 1 keer per 18 uur maximaal... Dat kunnen ze wel hebben

[ Voor 12% gewijzigd door FireDrunk op 13-11-2014 13:25 ]

[Nindustries]

FireDrunk schreef op donderdag 13 november 2014 @ 12:42:
https://wiki.samba.org/index.php/SMB3#Multi_Channel

https://git.samba.org/?p=...ads/master3-multi-channel

Ze zijn er lang mee bezig hoor

Sure, mijn punt was het ondersteunen ervan, niet SMB3 zelf

[Verwijderd]

FireDrunk schreef op donderdag 13 november 2014 @ 13:24:
Dan zet je hem heel hoog: 65536 ofzo Dat is 1 keer per 18 uur maximaal... Dat kunnen ze wel hebben

Disable of timer=0 werkte niet en max timeoput is 300 seconden. Hij staat nu op 300 seconden, dat zou voldoende moeten zijn lijkt mij. Gezien het gebruik staat hij toch of continu te streamen of volledig stil. Dus met een 30 seconde timer moet dat goed gaan. (Ik zal eens kijken of hij uberhaupt nog parkt, want als je in dat frame schijf access heb reset de tijd tot headpark en parkeer je feitelijk nooit.

[ Voor 13% gewijzigd door Verwijderd op 13-11-2014 14:03 ]

[Aaargh!]

Emcee schreef op woensdag 12 november 2014 @ 23:24:
Ga een simpel nasje bouwen van een pc die er toch staat met de volgende specs:
Mobo: Gigabyte ma785gt-ud3h AM3
Cpu: Amd dual core x2-240 socket AM3 2,8GHz
Cpu cooler: Coolermaster hyper Z600
Memory: 6 GB ddr3
Power: Cooler Master real power 450W
Case: Cooler Master Gladiator 600

Wil er 6x4TB WD Green in doen, en dan met ZFS een RaidZ2 maken voor een netto opslag van 16TB

Aangezien deze machine geen ECC geheugen heeft moet je er heel goed op letten dat je ZFS checksums uitschakelt. Integriteit van data is dan ook niet gegarandeerd.

[FireDrunk]

Whut? Gaan we mensen nu adviseren om ZFS checksums uit te zetten??? Waar komt dat vandaan?

[Verwijderd]

Aangezien deze machine geen ECC geheugen heeft moet je er heel goed op letten dat je ZFS checksums uitschakelt.

[MTDjassen]

*MTDJassen met zijn non-ECC RAM kreeg bijna de tweede hartverzakking van vandaag, maar gelukkig bleek het allemaal onwaar.

[kdbruin]

MTDjassen schreef op donderdag 13 november 2014 @ 13:15:
-overigens: nog een specifieke versie van WDIDLE? Op de supportpage van de WD20EZRX staat hij niet...

Ik heb Ultimate Boot CD op een USB stick staan. Hier staat een versie van WDIDLE op die werkt met de WD20* maar ook de WD30* disks. Ik weet alleen zo niet de versie uit m'n hoofd. En het kan zijn dat er 2 versies op staan (is voor een aantal tools het geval).

[Verwijderd]

Tja, de FUD-machine van ECC zeeloten draait overuren kennelijk. Maar je hoeft je van al die onzin niets aan te trekken.

In al mijn ervaring van mensen die ik spreek met problemen; is het nog nooit voorgekomen dat ik iemand met een kapotte file heb gezien waarbij de redundancy niet is aangetast. Kortom, dat je files stuk gaan door non-ECC RAM is een extreem geval. Het grootste probleem is dat je zonder ECC RAM je End-to-End protection verliest. Maar permanente corruptie is zeer uitzonderlijk. Gedurende mijn tests met corrupt RAM kon alle corruptie weer worden hersteld na een scrub met goed geheugen. Sowieso kun je door de checksums altijd vaststellen of er corruptie heeft plaatsgevonden. Dus checksums uitschakelen is totaal van de zotte.

[Aaargh!]

Verwijderd schreef op donderdag 13 november 2014 @ 14:41:
In al mijn ervaring van mensen die ik spreek met problemen; is het nog nooit voorgekomen dat ik iemand met een kapotte file heb gezien waarbij de redundancy niet is aangetast. Kortom, dat je files stuk gaan door non-ECC RAM is een extreem geval.

Als je pech hebt en je doet een scrub met kapot geheugen en geen manier om dit te detecteren dan is je hele pool onherstelbaar beschadigd.

Een scrub checked de checksum van je data, mocht dit precies op een kapot stuk van je RAM terecht komen dan is die checksum altijd fout. waarna het systeem het probeert te herstellen vanaf de RAIDZ, aangezien je RAM niet goed is gaat ook dit mis en wordt de 'herstelde' (en nu kapotte data) teruggeschreven naar je schijf.

Zonder checksums kan er wat fout gaan maar ben je alleen dat stukje kwijt, met checksums ben je potentieel ALLE data kwijt.

[Aaargh!]

FireDrunk schreef op donderdag 13 november 2014 @ 14:03:
Whut? Gaan we mensen nu adviseren om ZFS checksums uit te zetten??? Waar komt dat vandaan?

Omdat zonder ECC geheugen de kans groot is dat je je hele pool totaal in de vernieling helpt. 1 kapot bitje op de verkeerde plek tijdens een scrub en je hele pool is kaputt.

[Verwijderd]

Heb je daar documentatie voor, Aaargh!?

Heb je zelf tests uitgevoerd bijvoorbeeld? Wat waren je bevindingen?

[Pantagruel]

Aaargh! schreef op donderdag 13 november 2014 @ 16:06:
[...]

Omdat zonder ECC geheugen de kans groot is dat je je hele pool totaal in de vernieling helpt. 1 kapot bitje op de verkeerde plek tijdens een scrub en je hele pool is kaputt.

Graag getallen, details en een goede onderbouwing, geen onderbuikgevoelens aub. Hoe groot is die 'kans' dan, Nakende of astronomisch klein?

Jammer genoeg is ECC RAM alles behalve het paardenmiddel dat alle problemen voorkomt/oplost. Gemakshalve sluit je uit dat evt. problemen van andere bronnen afkomstig kunnen zijn (mobo aansluitingen, slechte bekabeling, netwerk bron die data aanlevert,etc.). De hardware is verre van perfect, in t geval van server grade hardware wellicht zorgvuldig getest, maar niet 100% vrij van fouten.
Het is al vaker ter sprake gekomen, als je het tot het minimale wilt beperken zul je de hele keten moeten afdekken en zal zelfs de software die het bestand aanmaakt moeten verifieeren dat t allemaal juist is verlopen met het wegschrijven van t bestand.

[Aaargh!]

Verwijderd schreef op donderdag 13 november 2014 @ 16:23:
Heb je daar documentatie voor, Aaargh!?

Hier snel wat info:

http://research.cs.wisc.e...zfs-corruption-fast10.pdf

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

Op het moment ff geen tijd om hier verder op in te gaan, PostNL stond net voor de deur met hardware voor een nieuwe router (met ECC geheugen) en die moet met enige spoed in elkaar gezet, geinstalleerd en geconfigureerd.

[Verwijderd]

Precies dat document gaat in op End-to-End data integrity, niet op permanente corruptie. Voor thuisgebruikers is dat laatste heel belangrijk; voor bedrijven die transacties doen enzo is het eerste veel belangrijker, omdat zij toch duizend backups hebben maar backups heb je weinig aan als je applicaties toch corrupte data kunnen ontvangen van het filesystem.

Je biedt geen documentatie om je krachtige uitspraken te ondersteunen, met name:

... zonder ECC geheugen de kans groot is dat je je hele pool totaal in de vernieling helpt

Als je geen tijd of zin hebt om uitleg te geven over dergelijke uitspraken, zou ik je toch willen verzoeken ze niet te maken. Het komt erg neer op een flame op dit moment. Want je zegt iets waarvan je denk ik weet dat het heel provocerend en stemmingsmakend is, wilt vervolgens niet ingaan op de kwestie om een degelijke onderbouwing te geven, maar laat ons achter om de scherven op te ruimen.

Verder stel ik ook voor om een apart topic te maken over ECC en ZFS, om het probleem van de alsmaar terugkomende discussie en twee-wekelijkse herhaling van alle argumenten in te dammen.

[player-x]

Aaargh, volgens mij gebruik je hier de zelfde methode als mensen die zeggen, ik doe geen autogordel om, want als ik het water terecht kom, heb ik een grotere kans om te verdrinken.

Alleen word in die redenatie er even snel over het hoofd gezien dat men bij de meeste ongelukken niet te water raakt, en boven dien dat, zelf als je te water raakt, en je overlevingskansen door de gordels verhoogt worden daar je niet met je hoofd tegen de vooruit aan smakt en dus bij bewust zijn blijft, en je daar naast aanzienlijk minder kans hebt op zwaardere verwondingen die je bewegingsvrijheid belemmeren, en ook nog eens vergeet dat de meeste auto's die te water raken gewoon recht op blijven, en die gordels al helemaal geen belemmering waren om te beginnen.

[MTDjassen]

On a positive note: WDIDLE met FreeDos op een bootable USB heeft al mijn schijven netjes op 300s gezet (de max). Met een factor 38 minder parks moet ik het toch een behoorlijke tijd nog uithouden. Hij herkende wel één van m'n schijven niet, dus moest even SATA kabeltjes omwisselen halverwege maar als het goed is houdt hij nu weer een tijdje vol. Thanks voor de tips iedereen.

[GioStyle]

Uit de tweede bron van Aaargh!:

"Bad RAM" isn't necessarily non-ECC RAM. I've deployed bad ECC RAM in the past, where even though they are error correcting, they fail frequently, and need to be replaced. Further, ECC RAM isn't necessarily "Good RAM". I've deployed non-ECC RAM that has been in production for years, and have yet to see a corrupted file due to not having error correction in the hardware. The point is, you can have exceptional non-ECC "Good RAM" that will never fail you, and you can have horrid ECC "Bad RAM" that still creates data corruption.

What you need to realize is the rate of failure. An ECC RAM module can fail just as frequently as a non-ECC module of the same build quality. Hopefully, the failure rate is such that ECC can fix the errors it detects, and still function without data corruption. But just to beat a dead horse dead, ECC RAM and hardware failure rates are disjointed. Just because it's ECC RAM does not mean that the hardware fails less frequently. All it means is that it detects the failures, and attempts to correct them.

[matty___]

Weet iemand of de Atoms van tegenwoordig (Intel Atom D510m, Intel Atom C2758) voldoende power hebben voor een raidz1, lz4 en plexmedia transcoding?

Ben van plan mijn nas op nieuw op te zetten en te downsizen qua behuizing en stroomverbruik.

[Verwijderd]

Voor ZFS en LZ4 zeker, maar Plex transcoding durf ik niet te zeggen. Denk dat dat het zwaarste zal zijn. Dat gezegd, het is wel een quadcore dus als de transcoding multithreaded is en niet al te zwaar, dan gaat dat prima lukken. Maar single threaded is de Avoton helemaal niet zo snel.

[player-x]

De Avoton C2758 is een echte 8 core CPU zonder HT.

Maar ik zou zeggen ga voor een S1150 bord, die verbruiken idle nouwelijks meer dan een C2758, het enige waar je op moet letten is dat je een zo zuinig mogelijk moederbord kiest.

HWI.info test behoorlijk veel borden inclusief hun idle verbruik steeds met de zelfde CPU, selecteer zoveel mogelijk goedkopere kale borden, die zijn het zuinigst in verbruik, en dat kan zelfs zomaar 30W schelen.

Het verschil tussen een duo en quad CPU is trouwens ongeveer 4W idle, 8 euro/jaar.

Een S1150 heeft gewoon een hele hoop meer kracht wanneer je het nodig hebt, en gelukkig gaat dat tegenwoordig zonder enorm ilde verbruik.

[GioStyle]

player-x schreef op donderdag 13 november 2014 @ 21:24:

HWI.info test behoorlijk veel borden inclusief hun idle verbruik steeds met de zelfde CPU, selecteer zoveel mogelijk goedkopere kale borden, die zijn het zuinigst in verbruik, en dat kan zelfs zomaar 30W schelen.

Er kunnen inderdaad grote verschillen zitten qua verbruik van moederborden. Echter zou ik niet HWI.info als bron gebruiken, omdat daar resultaten verschijnen waarvan ik denk of je metingen kloppen niet of ze weten niet wat ze aan het doen zijn.

Het verschil tussen een duo en quad CPU is trouwens ongeveer 4W idle, 8 euro/jaar.

Het verschil qua idle verbruik tussen een Intel duocore en quadcore CPU is <1 watt.

[Emcee]

Over de ECC discussie, weet dat het beter is om wel te gebruiken maar verwacht toch dat de data ook met ZFS (zonder ECC) beter beschermd is tegen corruptie dan een willekeurig raid systeem.
Intel NC is besteld
WDIDLE ga ik ook zeker even draaien vooraf

Heb ooit gelezen dat je niet de volledige hdd beschikbaar moet stellen aan ZFS om problemen met de grootte van toekomstige vervangende schijven te voorkomen, is dit een reeel probleem waar mensen rekening mee houden? Bron: http://www.freebsddiary.org/zfs-with-gpart.php

[thibautb]

Ik vind eigenlijk dat er een appart topic zou gestart moeten worden over ecc memory, het is hier een topic over of je nas goed of niet is, maar soms gaat het hier 3 pagina's lang over ecc memory of het wel of niet goed is en dat is toch niet zo handig voor degene die hier antwoorden/ vragen zoeken.

[A1AD]

thibautb schreef op donderdag 13 november 2014 @ 22:23:
Ik vind eigenlijk dat er een appart topic zou gestart moeten worden over ecc memory, het is hier een topic over of je nas goed of niet is, maar soms gaat het hier 3 pagina's lang over ecc memory of het wel of niet goed is en dat is toch niet zo handig voor degene die hier antwoorden/ vragen zoeken.

Ik vind dit hier net wel relevant alleen moet deze discussie niet elke week opnieuw voorbij komen.