De CSL/OT-kroeg

[FireDrunk]

Oh wow, dat is cool

[Q]

Sorry ben gewoon een super nerd

[dcm360]

Zo af en toe vraag ik me wel eens af waarom ik iets niet eerder bedacht, zoals vanmiddag: het meeste geschikte protocol om een harddisk te klonen naar mijn server is uiteraard iSCSI. Niet bepaald een verrassing dat het twee keer zo snel gaat vergeleken met Samba of SSHFS...

[Q]

Handig inderdaad. Ik deel zelf permanent een disk via iSCSI die een kloon bevat van mijn Mac boot/data disk (dagelijks bijgewerkt). iSCSI is letterlijk een soort van USB maar dan met een hele lange kabel zodat je die disks niet bij je computer hoeft neer te leggen.

[A1AD]

dcm360 schreef op maandag 18 januari 2016 @ 14:40:
Zo af en toe vraag ik me wel eens af waarom ik iets niet eerder bedacht, zoals vanmiddag: het meeste geschikte protocol om een harddisk te klonen naar mijn server is uiteraard iSCSI. Niet bepaald een verrassing dat het twee keer zo snel gaat vergeleken met Samba of SSHFS...

Met welk programma maak jij clones?

[dcm360]

Met dd. Een andere methode waarmee ik een schijf terug kan klonen in een bootable state heb ik vooralsnog niet gevonden helaas.

[Q]

clonezilla gaat sneller denk ik als de disk niet vol zit. Die kloont alleen de data in tegen stelling tot dd, die ieder bitje overzet. Helemaal handig als de data ook goed te compressen is.

[dcm360]

Hm, die zat niet helemaal correct in mijn geheugen, nu ik zo lees dat die gewoon btrfs ondersteunt. Waarschijnlijk verwarde ik het een beetje met de ondersteuning voor ZFS, en bij gebrek daaraan viel mijn keuze op dd met de optie conv=sparse. Welja, uiteindelijk heb ik toch nog langer gedaan over het kunnen booten van de installatiecd dan dat het klonen geduurd heeft

[HyperBart]

Dankzij FireDrunk en 3 uur tijd gisteren een achtergebleven controller van IR naar IT geflasht (HyperBart in "Troubleshooting en oorzaak ZFS cksum errors").

Controllers draaien nu op P19 en vooral in IT mode, de Dell H200 speelde wel wat op maar na paar keer wisselen tussen FreeDOS en UEFI shell (builtin via SuperMicro moederbord) is het uiteindelijk toch gelukt.

Die checksum errors blijf ik nog altijd iets raars vinden, maar ik hou het voorlopig op een probleempje met de driver of FW, over FW twijfel ik nog wat, want het was over twee controllers gelijktijdig, enige common divider is de driver daar.

Toch maar even extra backupje trekken, weer een goede gelegenheid.

[DeRooney]

Ik zit met een aankomend projectje waarvan ik mij afvraag of het binnen Opslag technologie valt of binnen Internetproviders/hostings.

Ik ga een dezer maanden een raspberry pi kopen (pi 2b) welke ik wil gebruiken om mijn tv weer smart te maken. Maar ook om mijn eigen cloud te creëren. Nu had ik het erover met 2 vrienden dat we op die manier relatief eenvoudig ook ervoor kunnen zorgen dat we alledrie een soort backup driehoek hebben: van de data van ieder van ons zijn er 2 backups: 1 backup bij de 1, 1 backup bij de ander.

Ik wil nu uit gaan vogelen hoe ik dat het beste kan gaan organiseren (welke software voor het backuppen en synchroniseren etc). Alleen kan ik met mijn zoekopdrachten nog niet een soortgelijk iets vinden. En voordat ik een topic open in het verkeerde forum vraag ik eerst even of ik in dit forum op de juiste plek zou zijn.

Dank alvast!

	backupt bij:
persoon nr	1	2	3
1		x	x
2	x		x
3	x	x

[Q]

Waarom zou je dat doen? Voor 5 dollar per maand kun je gewoon ongelimiteerd data backuppen bij Backblaze of Crashplan. Dit gaat een hoop werk opleveren en het is waarschijnlijk fout-gevoelig. Als je het gewoon een leuk projectje vind, prima natuurlijk.

[DeRooney]

misschien wel met name dat laatste...

maar het kwam er bij mij meer op neer dat ik toch die pi straks heb en ook mijn opslag ruimte voldoende is om hieraan te hangen. Vervolgens dat we ieder onze backups graag extern hebben en zo kwamen we van het een in het ander..

[HyperBart]

Om gewoon fysiek een andere versie te hebben vond ik BitTorrent Sync wel een goeie daarvoor. Als ik hoor dat je maar een rPI nodig hebt heb ik ook niet het idee dat het immens veel data is wat je wil veiligstellen.

Alleen eens kijken of BTSync ook versionering ondersteunt, als dat het geval is heb je imho een prima en simpel systeempje.

Eigenlijk zelf nooit bij nagedacht maar zelfs voor mij zou dat een prima manier zijn om de meest kritieke eigen geproduceerde data veilig te stellen

[ Voor 18% gewijzigd door HyperBart op 22-01-2016 12:39 ]

[Q]

arjoderoon schreef op vrijdag 22 januari 2016 @ 12:10:
misschien wel met name dat laatste...

maar het kwam er bij mij meer op neer dat ik toch die pi straks heb en ook mijn opslag ruimte voldoende is om hieraan te hangen. Vervolgens dat we ieder onze backups graag extern hebben en zo kwamen we van het een in het ander..

Als je het ook een leuk projectje vind, doe het dan ook goed. En met goed bedoel ik: bouw er wat scriptjes omheen die de boel bewaakt, zodat je er niet achter komt dat de backup al drie maanden niet liep maar je niets door had

[FireDrunk]

@Q, hoe heb jij die info van blktrace en blkparse omgezet naar zo'n mooi grafiekje?

[Q]

FireDrunk schreef op vrijdag 22 januari 2016 @ 19:39:
@Q, hoe heb jij die info van blktrace en blkparse omgezet naar zo'n mooi grafiekje?

Eigenlijk super getto: ik heb met grep cut awk de reeks met sector locaties uit de file gesneden en die in excel geplakt -> scatter/gather plot en je bent klaar.

Edit: beetje eenmalige actie, mooier is om met python en matplotlib wat mooiers te genereren. dat je kan hergebruiken.

[ Voor 14% gewijzigd door Q op 22-01-2016 21:37 ]

[FireDrunk]

Mja, zat al te kijken naar CollectD support, maar dat is er niet...
Leek mij leuk om iets permanenters mee te doen.

[Q]

NAS CPU / MOBO overzicht geupdated met wat Skylake. Maar Skylake biedt eigenlijk niet zoveel...

https://docs.google.com/s...LHkrg/edit#gid=1721926988

[FireDrunk]

Leuk overzichtje! Skylake bied in mijn ogen vooral DDR4, en dus 64GB RAM per systeem...
Waar heb je overigens je ST en MT scores vandaan? PassMark online?

[Q]

Ja dat zijn passmark scores. Die van de 1220 en 1230 zijn helaas nog niet te vinden.

[FireDrunk]

Mijn E5 2620v3 scoort niet eens heel goed Ik zit op ~1800 ST en ~9980 MT ofzo.
Dus mijn efficiency cijfer is 'maar' 9 ofzo. (Heb er 175,- voor betaald)

[ Voor 9% gewijzigd door FireDrunk op 27-01-2016 11:14 ]

[dcm360]

Hm, misschien toch de 1240Lv5 die ik nu in een kandidaatlijstje heb gezet maar een beetje heroverwegen nu ik dit zo lees en een beetje verder kijk. De 1260Lv5 lijkt op zich al wat interessanter voor een niet veel hogere prijs (maar wel flink hoger TDP), maar wellicht moet ik dat nog eens gaan uitzoeken op een moment dat ik daadwerkelijk nieuw spul wil hebben, of op het moment dat mijn huidige dingetje echt te weinig aan 32GB heeft. 64GB DDR3 is, ehm, nogal prijzig. Prijziger dan 64GB DDR4 plus CPU en moederbord...

[Q]

TDP is meestal niet zo'n issue.

Die 2620 voor 175 lijkt mij een super koopje.

[FireDrunk]

Ik heb 380 euro betaald voor mijn 64GB geheugen, dus ook dat was niet duur. Totale combinatie was dus qua prijs/kwaliteit prima volgens mij...

[Q]

Heb eens wat ZFS resilver benchmarks gedaan, mogelijk al gezien in het ZFS topic. Klein artikeltje over gemaakt.

http://louwrentius.com/zf...various-raid-schemas.html

[FireDrunk]

Kleine tip, misschien wat duidelijker aangeven wat goed is en wat niet... Nu lijkt het alsof de hoogste de beste is

[Q]

Ja dat is wel netjes, alhoewel ik aan je verstand twijfel als je dat als lezer niet snapt.

Ik vind mijn artikel eigen slordig, ik ben het aan het herschrijven. Published.

[ Voor 30% gewijzigd door Q op 31-01-2016 12:40 ]

[Nindustries]

Iemand hier ervaring met dit plastieken doosje? Lijkt op zich nog een goedkoop alternatief voor de Chenbro Compact Server Chassis SR30169. Maarre.. zal wel nogal trillen

[ Voor 5% gewijzigd door Nindustries op 02-02-2016 15:29 ]

[Q]

Waarom zou je zoiet kopen? De kwaliteit is best slecht als ik het zo zie en met de componenten er bij ben je duurder uit dan een HP Microserver. Want je moet er ook nog een voeding bij kopen.

[Nindustries]

Was maar even aan het rondhoren, ik blijf bij mijn SR30169. Spijtig dat ze een generatie microservers overslaan, ik ben toch meer geneigd om een Skylake servertje dan een socket 1155. Oke het is duurder, maar ge krijgt er wel een verse generatie en 32GB DDR4 in de plaats

[Q]

Zie geen benchmark van vergelijkbare processor G3900t. Vraag me erg af hoeveel je er op vooruit gaat. De huidige 16 GB limiet is denk ik het enige issue met de Gen8.

[Verwijderd]

Q schreef op zondag 31 januari 2016 @ 11:44:
Heb eens wat ZFS resilver benchmarks gedaan, mogelijk al gezien in het ZFS topic. Klein artikeltje over gemaakt.

http://louwrentius.com/zf...various-raid-schemas.html

Ik heb niet je hele artikel gelezen, maar misschien wel even vermelden dat jouw controller maar PCIe x8 heeft - volgens mij 1.0 - en dus op 2GB/s gecapped is terwijl hij 16x SATA/300 levert. Dus bij 6 disks ben je ongeveer bandwidth capped. Dat verklaart denk ik waarom je 10-disk rebuild tijden zoveel hoger zijn. Want dat zou niet hoeven als je voldoende bandbreedte had. Je kunt dit zelf controleren door een paar disks via de chipset SATA aan te sluiten ipv de Highpoint controller.

[Q]

Verwijderd schreef op woensdag 03 februari 2016 @ 13:23:
[...]

Ik heb niet je hele artikel gelezen, maar misschien wel even vermelden dat jouw controller maar PCIe x8 heeft - volgens mij 1.0 - en dus op 2GB/s gecapped is terwijl hij 16x SATA/300 levert. Dus bij 6 disks ben je ongeveer bandwidth capped. Dat verklaart denk ik waarom je 10-disk rebuild tijden zoveel hoger zijn. Want dat zou niet hoeven als je voldoende bandbreedte had. Je kunt dit zelf controleren door een paar disks via de chipset SATA aan te sluiten ipv de Highpoint controller.

Die disks doen maar 100-110 MB/s dus met 10 disks haal ik 'maar' 1100 MB/s. In de praktijk zie ik met 'dstat' slechts een 'raw' bandbreedte gebruik van 400-600 MB/s afhankelijk van welke test ik draai en de aantallen betrokken disks.

Om heel eerlijk te zijn heb ik een sterk vermoeden dat met het toevoegen van meer disks op de een of andere manier de boel meer CPU-bound is (oude dual-core) processor. Ik zie per disk maar 50/60 MB/s en dat is 'slechts' 600 MB/s total.

Ergens zou ik deze test op nieuwere, snellere hardware willen draaien met dezelfde disks om zaken uit te sluiten, maar of ik daar tijd aan wil besteden (spullen heb ik) weet ik niet.

Ik weet vanuit het verleden dat mijn MDAMD array ook echt 1100 MB/s kon halen al met 10 disks ofzo.

[ Voor 3% gewijzigd door Q op 03-02-2016 14:29 ]

[Verwijderd]

Oke, maar dan is dit meer een hardwaretest dan een ZFS test. Dat is niet helemaal duidelijk als ik je artikel vluchtig doorlees - tenzij ik iets heb gemist. Ik denk inderdaad dat je met betere hardware - voornamelijk de controller - wel veel hogere snelheden zult behalen en het dus weinig uitmaakt hoeveel disks je in je pool hebt zitten. Zolang ze maar voldoende bandbreedte hebben. Latencyverschillen kunnen ervoor zorgen dat je niet je potentiële max haalt.

[Q]

Verwijderd schreef op woensdag 03 februari 2016 @ 14:36:
Oke, maar dan is dit meer een hardwaretest dan een ZFS test. Dat is niet helemaal duidelijk als ik je artikel vluchtig doorlees - tenzij ik iets heb gemist. Ik denk inderdaad dat je met betere hardware - voornamelijk de controller - wel veel hogere snelheden zult behalen en het dus weinig uitmaakt hoeveel disks je in je pool hebt zitten. Zolang ze maar voldoende bandbreedte hebben. Latencyverschillen kunnen ervoor zorgen dat je niet je potentiële max haalt.

Volgens mij zou de conclusie moeten zijn dat bij grotere VDEVs de CPU mogelijk de bottleneck wordt en niet de controller want die heeft bandbreedte zat. Dus de controller is het minste probleem, denk ik.

Ik zie nu net dat ik dit expliciet al in het artikel benoem als risico.

[ Voor 4% gewijzigd door Q op 03-02-2016 14:45 ]

[Verwijderd]

Dat is iets wat je zou kunnen testen. Wat is de CPU-belasting tijdens het rebuilden? Ik denk dat een dualcore al voldoende moet zijn om tien disks te laten rebuilden tegen maximale snelheid.

[Q]

Verwijderd schreef op woensdag 03 februari 2016 @ 16:10:
Dat is iets wat je zou kunnen testen. Wat is de CPU-belasting tijdens het rebuilden? Ik denk dat een dualcore al voldoende moet zijn om tien disks te laten rebuilden tegen maximale snelheid.

De dual-core staat op 60-90% en de load was 12 tijdens een 11 disk RAID-Z3 rebuild.

Dit zijn alle tests compleet (25% en 50% pool usage).



Edit: moeilijk te zeggen waar eventueel de CPU een limiet wordt. Mogelijk waren alle resultaten overall beter geweest met een snellere CPU.

[ Voor 20% gewijzigd door Q op 03-02-2016 21:29 ]

[Verwijderd]

Hmhm. Aangezien jouw HighPoint RocketRAID 2xxx een binary blob gebruikt, zou dat een deel van het hogere CPU-verbruik kunnen verklaren. Als je gewoon schijven als AHCI aansluit, verwacht ik een veel lagere CPU belasting en dus mogelijk ook hogere rebuildsnelheid - naast het feit dat de controller zelf minder latencyfluctuaties heeft doordat het tegen zijn bottleneck aankomt.

Kortom, ik verwacht dat als je 6 disks zou aansluiten op de chipset en de rest op een andere controller, je betere resultaten had gehad ook met je oudere dualcore.

Ik heb namelijk maar 6% belasting op mijn J1900 - wat een quadcore op 2GHz is, maar met weinig cache enzovoorts. Jounes draait op 2,8GHz en daar verwacht ik toch van dat hij qua IPC beter scoort dan een J1900 core.

[Q]

Ik zal eens kijken, ik heb zelf het idee dat de getallen hierboven eigenlijk heel realistisch zijn en ik verwacht zelf geen enkel of een minuscuul verschil.

[FireDrunk]

Telt BSD IOWAIT wel als CPU load? of is BSD zo lief om dat niet mee te rekenen? Want anders is 6% CPU load natuurlijk niet 'eerlijk'.

[Q]

Nou, ik vraag mij eigenlijk af wat voor load je hebt op een j1900 als je een RAID-Z3 met 11 disks resilvert. Ik betwijfel of je dan ook 6% ziet.

[HyperBart]

Ik kan binnenkort de tests eens herhalen met een hedendaagse setup à Xeon E3 1230v5, een sloot geheugen en 18/19 x 4TB op M1015 of nieuwe equivalenten op basis van LSI3008, dan hebben we toch al twee steekproeven.

Als iemand een cheap CPU'tje wil sponsoren die op het moederbordje past dan wil ik het ook eens herhalen met die CPU.

Op basis van deze discussie eens het volgende gelezen:
http://jrs-s.net/2015/02/...e-mirror-vdevs-not-raidz/

Dit stukje en dan vooral het bold stukje vond ik daar wel wat raar bij:

But wait, why would I want to trade guaranteed two disk failure in RAIDZ2 with only 85.7% survival of two disk failure in a pool of mirrors? Because of the drastically shorter time to resilver, and drastically lower load placed on the pool while doing so. The only disk more heavily loaded than usual during a mirror vdev resilvering is the other disk in the vdev - which might sound bad, but remember that it's only being heavily loaded with reads, whereas all of the remaining disks in a RAIDZ vdev are being much more heavily loaded with writes as well as reads during a resilver. Resilvering a mirror is much less stressful than resilvering a RAIDZ.

Hoezo worden nog werkende/overblijvende disks onder een RAIDZx VDEV ook beschreven tijdens resilvers ?

[Q]

Dat klopt inderdaad niet. Ik ben overigens goed bekend met dat artikel en 100% oneens met zijn / haar notie een betere efficientie willen dan 50% storage efficientie 'gierig' is.

[ Voor 9% gewijzigd door Q op 04-02-2016 20:22 ]

[HyperBart]

Q schreef op donderdag 04 februari 2016 @ 20:21:
Dat klopt inderdaad niet. Ik ben overigens goed bekend met dat artikel en 100% oneens met zijn / haar notie een betere efficientie willen dan 50% storage efficientie 'gierig' is.

Ja dat al helemaal, dat vond ik ook wel een topper qua "eeey euh even kort door de bocht".

Ik had het er net met FD nog over aan de telefoon, ik ben het eens met het feit dat je je VDEV's niet te wide moet maken. 10 disks met RAIDZ2 vind ik zo net prima, zo gaat het ook zijn bij de nieuwe build van een goede vriend van me. 2 x 10 disk RAIDZ2 in een 24 bay kast. Als hij dan later ooit nog snel moet uitbreiden kan hij een of twee mirrors bijsteken OF hij kan een VDEV upgraden door de disks een voor één te swappen. Dan krijgt hij door alleen maar de helft van de disks te vervangen toch al een uitbreiding in capaciteit.

FireDrunk is dan eerder (voor thuis) voor de mentaliteit om ze wat kleiner te houden en geen multi-VDEV pools te maken maar wat op te splitsen en pools en het vooral wat rustiger aan te doen en data te verwijderen...

Ik ben heel benieuwd naar de statistieken met je script, dat ga ik dan zeker eens laten lopen met verschillende configs.

We twijfelen nu alleen hoe we gaan migreren: even 2 x 10Gbit op de kop tikken of met je 450MB/s bonding aan de slag gaan om te ZFS senden en receiven. Met 10Gbit lijkt het me nog wel even een uitdaging om daar near line speeds te halen.

[ Voor 17% gewijzigd door HyperBart op 04-02-2016 21:30 ]

[Verwijderd]

Mij lijkt een 19-disk RAID-Z3 juist wel leuk als je de overhead tot een minimum beperkt wilt houden. Voor archive van bulkdata zou dat goed werken. Weinig overhead en tot 3-voudige parity protection. Meerdere vdevs is meerdere pools het beste omdat je bij het doorbreken van de redundancy niet de data op de overige vdevs in gevaar brengt. Maar dan zit je wel meer een fragmentatie van vrije ruimte die niet als één blok beschikbaar is.

Kortom, ligt helemaal aan de situatie wat het handigste is voor je.

[Q]

@CiPHER 100% eens over RAID-Z3. Een 24-disk RAIDZ3 met large block support zou ik aan durven. Dat was ook mijn plan toen large block support er nog niet was.

Achteraf had ik de RAID-Z3 moeten houden want de lage performance die ik mat met resilveren kwam door een kleine hoeveelheid (< 1 TB) kleine files. RAID-Z2 met 18 disks is wat 'dun'.

2 x 12 RAID-Z2 met large block support is ook prima natuurlijk.

Ik heb 4 disks van de HighPoint afgehaald en op de 4 vrije on-board SATA aansluitingen gezet. De test loopt nu met 50% pool usage. De vraag is hoeveel dit gaat verschillen met de performance op de HighPoint.

Stom, ik heb een 5e disk nodig die resivered dus de test craste. Ik test nu mirror, RAID-Z met 3 disks en dat is het, meer kan niet. Vraag me af of we er iets uit op kunnen maken.

[ Voor 12% gewijzigd door Q op 04-02-2016 22:14 ]

[Verwijderd]

Weet ik ook niet. Kan ook bij mij een keer testen met J1900 en ik heb ook nog een oudere AMD Quadcore (Q9350).

[HyperBart]

Verwijderd schreef op donderdag 04 februari 2016 @ 21:43:
Mij lijkt een 19-disk RAID-Z3 juist wel leuk als je de overhead tot een minimum beperkt wilt houden. Voor archive van bulkdata zou dat goed werken. Weinig overhead en tot 3-voudige parity protection. Meerdere vdevs is meerdere pools het beste omdat je bij het doorbreken van de redundancy niet de data op de overige vdevs in gevaar brengt. Maar dan zit je wel meer een fragmentatie van vrije ruimte die niet als één blok beschikbaar is.

Kortom, ligt helemaal aan de situatie wat het handigste is voor je.

Klopt, en dat is idd de afweging die FD ook aangaf door in pools te gaan splitsen.

Q schreef op donderdag 04 februari 2016 @ 22:01:
@CiPHER 100% eens over RAID-Z3. Een 24-disk RAIDZ3 met large block support zou ik aan durven. Dat was ook mijn plan toen large block support er nog niet was.

Achteraf had ik de RAID-Z3 moeten houden want de lage performance die ik mat met resilveren kwam door een kleine hoeveelheid (< 1 TB) kleine files. RAID-Z2 met 18 disks is wat 'dun'.

Hoe bedoel je dun? Had je 'm groter willen nemen à la 24 disks of bedoel je dat 2 disks voor pariteit op 18 disks wat te weinig is?

2 x 12 RAID-Z2 met large block support is ook prima natuurlijk.

Wat is nu eigenlijk de conclusie over het gebruik van large block? Ik had altijd begrepen dat een sub optimale VDEV in the end wel resulteert bij stevig wat plaatsverlies in hele wide VDEV's. Lost large blocks dit nu eigenlijk volledig op? Neen toch? Dat is de reden dat ik nog die optimale aantallen wil aanhouden namelijk.

Reden om ook voor de 2 x 10 RAIDZ2 VDEV te gaan was ook het feit dat er op dit moment al 6 x 4TB HGST Deskstar ter beschikking is van de huidige pool.

Bedoeling was dan om daarvoor 4 disks bij aan te schaffen, grand total 10 voor de HGST VDEV en dan een tweede VDEV te maken met 10 x de HGST Deskstar NAS, 4TB omdat die zogenaamd goedkoper zou zijn, maar ik was het nu even aan het checken en ik denk dat de vriend in kwestie ergens iets gemist heeft want voor die euro moeten we het nu niet laten.

Als large block het probleem van suboptimal aantallen helemaal wegneemt en er geen considerations zijn dan is de keuze aan hem of hij wil opsplitsen in VDEV's owv toekomstige expansie per VDEV dan of dat hij gedeelde ongefragmenteerde pariteit in Z3 wil.

Ik heb 4 disks van de HighPoint afgehaald en op de 4 vrije on-board SATA aansluitingen gezet. De test loopt nu met 50% pool usage. De vraag is hoeveel dit gaat verschillen met de performance op de HighPoint.

Stom, ik heb een 5e disk nodig die resivered dus de test craste. Ik test nu mirror, RAID-Z met 3 disks en dat is het, meer kan niet. Vraag me af of we er iets uit op kunnen maken.

[Verwijderd]

HyperBart schreef op donderdag 04 februari 2016 @ 23:03:
Wat is nu eigenlijk de conclusie over het gebruik van large block? Ik had altijd begrepen dat een sub optimale VDEV in the end wel resulteert bij stevig wat plaatsverlies in hele wide VDEV's. Lost large blocks dit nu eigenlijk volledig op? Neen toch?

Ja en nee.

large_blocks feature zorgt ervoor dat de maximale recordsize kan groeien van 128KiB naar 1024K. Dat is een ver-acht-voudiging en zorgt er ook voor dat de hoeveelheid slack drastisch afneemt doordat per disk er grotere blokgroottes worden gebruikt zodat alignment met de stripesize (of blokgrootte zoals geforceerd door ashift) minder verspilling - slack - oplevert.

Maar, dit geldt alleen voor data die een dergelijke grote recordsize kan gebruiken. Voor kleinere writes zal nog steeds een kleinere recordsize worden gebruikt en dan heb je dus weer wel veel slack. Hele kleine writes zoals bestanden kleiner dan de sectorsize, kan de 'embedded_date' feature uitkomst bieden. Deze zorgt ervoor dat de data direct in de pointer wordt opgeslagen en niet langer op een apart locatie op de disk die door de pointer wordt aangegeven. Dit zorgt voor aanzienlijke ruimtewinst bij veel kleine bestanden op een vdev met veel disks. Compressie kan de grootte zover doen verkleinen dat deze in de pointer past.

Maar voor kleine writes/files die niet in de pointer passen, en kleiner zijn dan de maximale recordsize, daar heb je dus nog steeds veel verlies. Sla je echter alleen grote bestanden op en schrijf je deze van A tot Z weg (geen kleine mutaties binnen de grote bestanden) dan kun je met large_blocks prima hele grote vdevs maken en hoef je je ook niet meer aan de regel te houden die zegt dat het aantal datadisks een macht van twee moet zijn.

Reden om ook voor de 2 x 10 RAIDZ2 VDEV te gaan

10 disks in RAID-Z2 blijft wat mij betreft nog de beste allround ZFS configuratie die er is. 20% overhead is te behappen en dubbelvoudige parity is goede bescherming, en met 8 data disks is het nog prima te doen qua slack / verloren ruimte.

[FireDrunk]

Bij 10 disks (in RAIDZ2) heb je toch juist 0% slack?

[ Voor 13% gewijzigd door FireDrunk op 04-02-2016 23:43 ]

[Verwijderd]

Als alle writes de maximale recordsize gebruiken, ja. Als de recordsize voor kleinere writes een breuk oplevert per disk, dan is er alsnog sprake van slack. De recordsize is niet een statisch iets. Het is een maximum. Kleinere writes zullen automatisch een kleine recordsize gebruiken en dan neemt de kans op slack toe naarmate je meer disks hebt in de pool.

[Q]

Ik weet niet echt wat ik er van moet maken. On-board controller brak?

code:

poolname,vdevtype,vdevcount,vdevsize,hours,minutes
pool-mirror-1-2,mirror,1,2,1,20
pool-raidz-1-3,raidz,1,3,1,37

Ik laat 'm nog een keer lopen.

code:

poolname,vdevtype,vdevcount,vdevsize,hours,minutes
pool-mirror-1-2,mirror,1,2,1,20
pool-raidz-1-3,raidz,1,3,1,36

Niet veel verschil dus.

[ Voor 24% gewijzigd door Q op 05-02-2016 16:26 ]

[A1AD]

Wooaa die SFF-8087 kabels zijn prijzig! Ik dacht de kabel te gebruiken die ik hier nog ergens liggen had maar mijn controller (lsi 9211-8i) ziet geen schijven

Het zal niet de forward variant zijn hoop ik, anders is de kaart defect.

Tips voor goedkope kabels?

[Pantagruel]

A1AD schreef op donderdag 11 februari 2016 @ 18:06:
Wooaa die SFF-8087 kabels zijn prijzig! Ik dacht de kabel te gebruiken die ik hier nog ergens liggen had maar mijn controller (lsi 9211-8i) ziet geen schijven

Het zal niet de forward variant zijn hoop ik, anders is de kaart defect.

Tips voor goedkope kabels?

Ebay en aanverwanten. De goedkopere kabels komen meestal uit China en dan duurt het wel langer.

[A1AD]

Pantagruel schreef op vrijdag 12 februari 2016 @ 14:20:
[...]


Ebay en aanverwanten. De goedkopere kabels komen meestal uit China en dan duurt het wel langer.

Ik vond ze zelf op ebay duur (incl. verzending). China, tsja weer een maand wachten...

[Pantagruel]

A1AD schreef op vrijdag 12 februari 2016 @ 21:33:
[...]


Ik vond ze zelf op ebay duur (incl. verzending). China, tsja weer een maand wachten...

Tja, als je ongeduldig bent dan zul toch al snel tegen de 20 euro per kabel kwijt zijn (excl. verzending).

[Dadona]

Ik heb ze destijds toch uit Nederland gehaald. Er staan wel wat kabels op Ebay, maar vooral die fancy blauwe kabels zijn super dun en de verbinding van connector naar draad was twijfelachtig.

[Pantagruel]

Ubuntu 16.04 LTS gaat ZFS uit de 'doos' doen vlgs Dustin Kirkland's blog en is t 'het FS voor container's '

[ Voor 9% gewijzigd door Pantagruel op 18-02-2016 14:52 ]

[Q]

Foutje.

[ Voor 93% gewijzigd door Q op 20-02-2016 18:17 ]

[Nindustries]

Zijn er eigenlijk veel mensen die goedkope 10Gb adapters kopen voor hun homelab? Vraag me af waarom deze niet meer gebruikt worden.
Ik geloof dat Chelsio drivers ter beschikking stelt voor esxi.

[Q]

Nindustries schreef op woensdag 24 februari 2016 @ 09:04:
Zijn er eigenlijk veel mensen die goedkope 10Gb adapters kopen voor hun homelab? Vraag me af waarom deze niet meer gebruikt worden.
Ik geloof dat Chelsio drivers ter beschikking stelt voor esxi.

Daar moet nog een SFP+ transceiver in ofwel koper of glas. Weet niet precies wat de prijzen zijn.

[HyperBart]

Nindustries schreef op woensdag 24 februari 2016 @ 09:04:
Zijn er eigenlijk veel mensen die goedkope 10Gb adapters kopen voor hun homelab? Vraag me af waarom deze niet meer gebruikt worden.
Ik geloof dat Chelsio drivers ter beschikking stelt voor esxi.

Een goede vriend van me heeft er net aangeschaft, Chelsio 2 kaartjes met een kabel erbij om tussen 2 servers een migratie te doen. Waren iets van een 100 EUR kwijt, wordt leuk om mee te spelen.

[Nindustries]

Een 100 euro voor 10Gbit tussen twee servers? Not bad, not bad at all

[HyperBart]

Jup, wel met Chelsio kaartjes, en volgens FireDrunk veroorzaken die nogal wat CPU load. Je kant altijd eens horen wat iemand hiervoor voor vraagt met betere kaartjes:

V&A aangeboden: Bloedsnel 10Gbit SFP setje aangeboden

[Q]

Zo zie je maar weer hoe onnodig ECC geheugen thuis is.

http://spectrum.ieee.org/...osmic-rays-and-bad-solder

Jaguar had 360 terabytes of main memory, all protected by ECC. I and others at the lab set it up to log every time a bit was flipped incorrectly in main memory. When I asked my computing colleagues elsewhere to guess how often Jaguar saw such a bit spontaneously change state, the typical estimate was about a hundred times a day. In fact, Jaguar was logging ECC errors at a rate of 350 per minute.

In the summer of 2003, Virginia Tech researchers built a large supercomputer out of 1,100 Apple Power Mac G5 computers. They called it Big Mac. To their dismay, they found that the failure rate was so high it was nearly impossible even to boot the whole system before it would crash.

The problem was that the Power Mac G5 did not have error-correcting code (ECC) memory, and cosmic ray–induced particles were changing so many values in memory that out of the 1,100 Mac G5 computers, one was always crashing.

[Verwijderd]

Het blijft je bezig houden hè.

Als ik die cijfers even doorreken en voor het gemak 1 ECC detected bitflip per TB RAM per minuut neem, komt dat neer op 46 bitflips per dag bij 32GiB, aangenomen dat het aantal bitflips zich lineair verhoudt tot de kwantiteit geheugen. Ik denk dat dat ver boven de rate is van reguliere systemen die met ECC zijn beveiligd. Daarbij zou je met MemTest86+ maar zeer zelden een bitflip per 24 uur zien waarbij het RAM geheugen ook 100% wordt gestressed, mogelijk meer dan zo'n supercomputer die daar waarschijnlijk net wat onder zit.

Kortom, het zou zomaar kunnen dat de cijfers die worden genoemd voor die supercomputer met IBM PPC processors, niet te vergelijken is met het aantal dat je zou zien bij een regulier x86 systeem met ECC geheugen.

Want als ik die cijfers neem zou ook ik elke dag dus 46 bitflips op al mijn systemen met 32GiB zou moeten hebben, en dat zou betekenen dat er elke dag toch wel een crash voorkomt en ZFS regelmatig checksum errors te zien krijgt. Dat is natuurlijk niet het geval.

[Q]

Verwijderd schreef op vrijdag 26 februari 2016 @ 22:27:
Het blijft je bezig houden hè.

Je hapt

Als ik die cijfers even doorreken en voor het gemak 1 ECC detected bitflip per TB RAM per minuut neem, komt dat neer op 46 bitflips per dag bij 32GiB, aangenomen dat het aantal bitflips zich lineair verhoudt tot de kwantiteit geheugen. Ik denk dat dat ver boven de rate is van reguliere systemen die met ECC zijn beveiligd. Daarbij zou je met MemTest86+ maar zeer zelden een bitflip per 24 uur zien waarbij het RAM geheugen ook 100% wordt gestressed, mogelijk meer dan zo'n supercomputer die daar waarschijnlijk net wat onder zit.

Ik snap niet hoe je aan deze getallen komt.

Wikipedia: Jaguar (supercomputer)

Deze machine bestaat uit 26520 nodes, doe dat x 2 voor 2 geheugen modules en je komt op 53040 modules en 350 flips per minuut komt neer op 10 filps per module per dag, een stuk lager dus.

Ik ben het met je eens dat dit wel evengoed een erg hoog getal is en ik denk dat die rate thuis inderdaad niet zo hoog ligt.

Mijn twee met ECC beveiligde servers, waarvan er 1 meestal uit staat, hebben nog nooit een geheugen fout gelogged. Een erg kleine sample om conclusies uit te trekken, maar ik deel het toch.

Kortom, het zou zomaar kunnen dat de cijfers die worden genoemd voor die supercomputer met IBM PPC processors, niet te vergelijken is met het aantal dat je zou zien bij een regulier x86 systeem met ECC geheugen.

Dat mac ding gebruikte PPC maar Jaguar gebruikt x86 CPUs (AMD). Dus deze vlieger gaat niet op.

Want als ik die cijfers neem zou ook ik elke dag dus 46 bitflips op al mijn systemen met 32GiB zou moeten hebben, en dat zou betekenen dat er elke dag toch wel een crash voorkomt en ZFS regelmatig checksum errors te zien krijgt. Dat is natuurlijk niet het geval.

De kans is aanzienlijk dat je zonder ECC geheugen (tijdelijke) fouten hebt die niet door ZFS worden waargenomen, dat ZFS niets ziet zegt niet zoveel. Of je server ECC events logt, dat zegt veel meer. Zonder ECC geheugen ben je blind.

Ik ben zeker niet van mening dat deze getallen 1-op-1 voor thuis gelden, zeker niet. Maar het is wel een interessant resultaat. Als de rate 1 per minuut was geweest ipv 350 dan zou je nog steeds op jaarbasis 10 flips per dimm zien. Dat zijn er 10 teveel.

[Verwijderd]

Is het een idee om deze discussie naar ECC geheugen voor zelfbouw ZFS NAS? te verplaatsen?

[Q]

Jij bent de moderator: edit: ik ben flauw, verplaats maar

[ Voor 46% gewijzigd door Q op 29-02-2016 03:16 ]

[Q]

Google onderzoek naar betrouwbaarheid van Flash:

http://0b4af6cdc2f0c59984...st16-papers-schroeder.pdf

Minder snel stuk, wel vaker bad blocks / unrecoverable errors (UE).

The drives in our study are custom designed high perfor- mance solid state drives, which are based on commodity flash chips, but use a custom PCIe interface, firmware and driver. We focus on two generations of drives, where all drives of the same generation use the same device driver and firmware. That means that they also use the same error correcting codes (ECC) to detect and cor- rect corrupted bits and the same algorithms for wear- levelling. The main difference between different drive models of the same generation is the type of flash chips they comprise.
Our study focuses on the 10 drive models, whose key features are summarized in Table 1. Those models were chosen as they each span millions of drive days, comprise chips from four different flash vendors, and cover the three most common types of flash (MLC, SLC, eMLC).

Als ik het goed lees is de leeftijd/wear level van het geheugen het enige wat impact heeft op de kans om een UE tegen te komen. Lees of schrijf gedrag heeft geen invloed.

We performed a detailed study of the effect of work- load on UEs. However, as noted in Section 5.1, we find no correlation between UEs and the number of read oper- ations. We repeated the same analysis for write and erase operations and again see no correlation.

[ Voor 84% gewijzigd door Q op 28-02-2016 11:00 ]

[Q]

code:

----total-cpu-usage---- -dsk/total- --net/ib0-----net/ib1-- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send: recv  send|  in   out | int   csw 
  1  47  41   0   0  10|   0  2867B|1245M 1240M:   0     0 |   0     0 |  40k   28k
  1  47  39   2   0  11|5360k 5325B|1244M 1235M:   0     0 |   0     0 |  40k   28k
  3  49  15  20   0  13|  63M   62k|1195M 1187M:   0     0 |   0     0 |  39k   25k

code:

------------------------------------------------------------
Client connecting to 10.0.4.3, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[  5] local 10.0.4.1 port 52572 connected with 10.0.4.3 port 5001
[  4] local 10.0.4.1 port 5001 connected with 10.0.4.3 port 44124
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-60.0 sec  71.9 GBytes  10.3 Gbits/sec
[  4]  0.0-60.0 sec  72.2 GBytes  10.3 Gbits/sec

Infiniband

[Verwijderd]

Probeer nog eens met een TCP window size van 8KiB.

[Q]

Verwijderd schreef op zaterdag 05 maart 2016 @ 01:54:
Probeer nog eens met een TCP window size van 8KiB.

Dat gaat zeker veel minder performance opleveren, maar waarom zou ik dit testen?

[Verwijderd]

Omdat elke keer als Windows 'involved' is, ik de default TCP window size op 8KiB zie staan, met lage performance tot gevolg.

Natuurlijk is het makkelijk om met Jumbo Frames / zeer hoge TCP Window Sizes de bandbreedte lekker te vullen, maar met interfaces met een hoog Bandwidth-Latency-Product (zoals 1Gbps+ Ethernet) is het niet altijd makkelijk de bandbreedte daadwerkelijk te benutten. Ik was benieuws hoeveel je inlevert op je Infiniband als de Window Size naar 8K gaat.

Dat gezegd, veel weet ik er niet van waarom de Window Size zo drastisch omlaag gaat als Windows de client is en hoe dit valt te tunen. Dat is altijd nog iets wat ik wilde uitzoeken.

[FireDrunk]

Windows doet gewoon aan auto tuning? Dus afhankelijk van de load gaat je window size omhoog?

https://technet.microsoft.com/en-us/library/hh826132.aspx

Hier kan je de instellingen wijzigen.

[Verwijderd]

Het punt is dat bij mensen waarbij ze lage CIFS performance hebben maar iperf met hoge TCP Window Size parameters wel genoeg bandbreedte haalt, de default TCP window size erg laag blijft (8K). Testen ze tussen twee ZFSguru machines, dan is de window size 128K en halen ze zonder tuning alles uit hun gigabit link.

Ik vermoed dat een wisselwerking tussen TCP stack van BSD en die van Windows niet altijd optimaal werkt. Het is echter niet altijd zo dat Windows geen goede CIFS performance haalt, dus waar het nou precies aan ligt weet ik ook niet. Maar als mensen slechte CIFS performance halen, is de TCP Window Size standaard altijd 8KiB met slechte iPerf performance tot gevolg. Dus ik had het vermoeden dat hier het probleem ligt.

Je geeft me een URL van Windows 10. Ik geloof best dat het daar beter is. Maar Windows 7 is denk ik vooral de client OS waar de performance problemen bij opdoken.

[ Voor 10% gewijzigd door Verwijderd op 05-03-2016 10:34 ]

[Q]

Ok helder, ik draai geen Windows en geen BSD dus ik geloof het wel, om eerlijk te zijn.

Met een single transfer haal ik trouwens 15 Gbit, terwijl de kaartjes 20 Gbit zijn. Mogelijk valt er nog wat te tunen, maar ik heb ze in mijn HP Microservers gestopt en dat zijn niet de grootste snelheidsmonsters.

[Pantagruel]

Verwijderd schreef op zaterdag 05 maart 2016 @ 10:33:
Het punt is dat bij mensen waarbij ze lage CIFS performance hebben maar iperf met hoge TCP Window Size parameters wel genoeg bandbreedte haalt, de default TCP window size erg laag blijft (8K). Testen ze tussen twee ZFSguru machines, dan is de window size 128K en halen ze zonder tuning alles uit hun gigabit link.

Ik vermoed dat een wisselwerking tussen TCP stack van BSD en die van Windows niet altijd optimaal werkt. Het is echter niet altijd zo dat Windows geen goede CIFS performance haalt, dus waar het nou precies aan ligt weet ik ook niet. Maar als mensen slechte CIFS performance halen, is de TCP Window Size standaard altijd 8KiB met slechte iPerf performance tot gevolg. Dus ik had het vermoeden dat hier het probleem ligt.

Je geeft me een URL van Windows 10. Ik geloof best dat het daar beter is. Maar Windows 7 is denk ik vooral de client OS waar de performance problemen bij opdoken.

De performance problemen van Windows 7 bij gebruik van Infiniband (IB) en cifs zijn te wijten aan het feit dat Win 7 cifs geen multi-path ondersteuning biedt. IB kan 8 parallelle transfers aan maar Win 7 knijpt de boel af tot slechts 1 transfer en beperkt dus je bandbreedte. Als je een SRP target inricht dan vallen de beperkingen weg en kan Win7 volle bak over IB (bij gebruik van een RAM disk als SRP target 900+ MB/sec over 10 Gbit IB onder linux). Linux naar linux laat dezelfde getallen zien. Met BSD+IB en windows heb ik geen ervaring, de IB attached storage draait linux en ZoL.

[Verwijderd]

De problemen die ik hoorde van mensen die ZFSguru gebruiken, zijn mensen met regulier gigabit ethernet, dus geen Infiniband. Met een hogere TCP window size behalen ze 900Mbps+ met iPerf, maar zonder override valt deze terug tot 8KiB en is ook met iPerf de bandbreedte vele malen lager. Dat heeft vervolgens ook zijn invloed op de daadwerkelijk behaalde CIFS performance. Niet iedereen heeft hier last van, dus ik weet ook niet precies wat de oorzaak is. Maar ik vermoed dus iets tussen Windows 7 en BSD en mogelijk in combinatie met bepaalde netwerkdrivers (Realtek?!).

[Pantagruel]

Verwijderd schreef op maandag 07 maart 2016 @ 16:47:
De problemen die ik hoorde van mensen die ZFSguru gebruiken, zijn mensen met regulier gigabit ethernet, dus geen Infiniband.

De IB was vanwege Q:

Q schreef op zaterdag 05 maart 2016 @ 01:32:

code:

----total-cpu-usage---- -dsk/total- --net/ib0-----net/ib1-- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send: recv  send|  in   out | int   csw 
  1  47  41   0   0  10|   0  2867B|1245M 1240M:   0     0 |   0     0 |  40k   28k
  1  47  39   2   0  11|5360k 5325B|1244M 1235M:   0     0 |   0     0 |  40k   28k
  3  49  15  20   0  13|  63M   62k|1195M 1187M:   0     0 |   0     0 |  39k   25k

code:

------------------------------------------------------------
Client connecting to 10.0.4.3, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[  5] local 10.0.4.1 port 52572 connected with 10.0.4.3 port 5001
[  4] local 10.0.4.1 port 5001 connected with 10.0.4.3 port 44124
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-60.0 sec  71.9 GBytes  10.3 Gbits/sec
[  4]  0.0-60.0 sec  72.2 GBytes  10.3 Gbits/sec

Infiniband

Met een hogere TCP window size behalen ze 900Mbps+ met iPerf, maar zonder override valt deze terug tot 8KiB en is ook met iPerf de bandbreedte vele malen lager. Dat heeft vervolgens ook zijn invloed op de daadwerkelijk behaalde CIFS performance. Niet iedereen heeft hier last van, dus ik weet ook niet precies wat de oorzaak is. Maar ik vermoed dus iets tussen Windows 7 en BSD en mogelijk in combinatie met bepaalde netwerkdrivers (Realtek?!).

Het zou me niet helemaal verbazen als er schommelingen zijn met RealTek (of Broadcom) gebaseerde nic's, ondanks dat ze tegenwoordig behoorlijk goed werken (was in t verleden wel anders).
Het probleem kan soms ook zijn dat moederbord producent hun 'eigen variant' draaien van een RealTek nic waardoor er driver incompatibiliteit ontstaat (Intel heeft wel eens een "eigen" RealTek nic gehad op een budget bordje) en je met *nix-achtigen tegen rare problemen aanliep.

Wat dat betreft lijkt het devies voor *nix dus nog steeds 'neem een Intel based nic' te zijn.

[FireDrunk]

Q schreef op zaterdag 05 maart 2016 @ 01:32:

code:

----total-cpu-usage---- -dsk/total- --net/ib0-----net/ib1-- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send: recv  send|  in   out | int   csw 
  1  47  41   0   0  10|   0  2867B|1245M 1240M:   0     0 |   0     0 |  40k   28k
  1  47  39   2   0  11|5360k 5325B|1244M 1235M:   0     0 |   0     0 |  40k   28k
  3  49  15  20   0  13|  63M   62k|1195M 1187M:   0     0 |   0     0 |  39k   25k

code:

------------------------------------------------------------
Client connecting to 10.0.4.3, TCP port 5001
TCP window size: 4.00 MByte (default)
------------------------------------------------------------
[  5] local 10.0.4.1 port 52572 connected with 10.0.4.3 port 5001
[  4] local 10.0.4.1 port 5001 connected with 10.0.4.3 port 44124
[ ID] Interval       Transfer     Bandwidth
[  5]  0.0-60.0 sec  71.9 GBytes  10.3 Gbits/sec
[  4]  0.0-60.0 sec  72.2 GBytes  10.3 Gbits/sec

Infiniband

Wat voor kitje gebruik je?

[Q]

Q in "De CSL/OT-kroeg"

Drie stuks van deze in drie HP Microserver Proliants G8 met 10 GB geheugen.
Het verkeer is tussen twee van deze machines.

Ceph cluster!

Wel fragiel want de Gen8 is half-height en de kaarten zijn full height.
In de toekomst wil ik de hardware overzetten tussen mijn download server en mijn 71 TB NAS.

[ Voor 30% gewijzigd door Q op 08-03-2016 12:50 ]

[rikadoo]

Ik ga een Norco RPC 4220 halen met 20 bays, nu lees ik hier gemengde berichten over. Is er iemand die ervaring hiermee heeft met deze kast?

Lees veel problemen met backplanes etc.

[jacovn]

Ik heb 2 maal een 4220 jaren gebruikt (ze staan uit tenzij ik ze gebruik dus qua uren is het niet zo veel)
2 defecte backplanes totaal. Dat was direct bij aanschaf, daarna geen issue meer gehad.

[Q]

http://arstechnica.com/ap...les-new-apfs-file-system/

Apple's nieuwe file system doet niet aan data checksumming. Dat is opvallend, want ZFS en BTRFS doen het wel. Het schijnt dat de reden met name is dat ze de onderliggende storage betrouwbaar genoeg achten (doet al ECC in hardware) dat ze het niet zelf nog eens doen.

Opvallend.

[Q]

YouTube: Intel What Is the Value of Your Data?

Intel promoot haar SSD producten door wat stats vrij te geven over HDD silent data corruptie statistieken.
Hun stats: dat 1 op de 215 drives* in een jaar een silent data corruptie bit heeft.

* SAS Nearline drives in een datacenter 24/7.

[Nindustries]

Heeft er iemand al eens naar infinit.sh gekeken?
Zou wel cool zijn om een mediacollectie te stripen over verschillende servers van de mensen hier, met een replicationfactor >1. Ook is er een docker volume plugin, waardoor je simpel een plex container kan starten ermee.

Geinteresseerden?

Je kan blijkbaar ook zonder hun 'hub' functioneren door config files te distribueren.

[ Voor 13% gewijzigd door Nindustries op 25-08-2016 16:27 ]

[Verwijderd]

Ik ben van plan één van mijn fileservers te upgraden van een 10-disk RAID-Z2 naar een 19-disk RAID-Z3, dus 9 disks erbij. Probleem is wel dat enkele disks 5400rpm-class zijn, en dat natuurlijk niet echt handig werkt. Dat gezegd, het is een backup server dus snelheid is niet extreem belangrijk; als hij maar in een nacht kan syncen en weer uit kan gaan.

Deze schijf is nu voor €79 (3TB, 7200rpm, Toshiba) pricewatch: Toshiba DT01ACA300, 3TB. Sommigen zeggen dat ze een rebranded Hitachi kregen, dat zou goed nieuws zijn. Toch niet heel bijzondere performance voor een 7200rpm schijf; mijn 6TB WD Green is sneller zie sequential I/O, want die heeft 1200GB ipv 1000GB platters. Dat is dan kennelijk al genoeg om de gap tussen 5400rpm-class en 7200rpm te overbruggen.

Maar prijstechnisch zou deze upgrade het beste zijn heb ik berekend; want dit is de goedkoopste schijf per TB (26 euro per TB - anderen zijn al gauw 35 euro per TB). En uitbreiden naar een RAID-Z3 betekent dat ik er qua parity overhead op vooruitga, terwijl 3 schijven kunnen uitvallen. Ik beschouw een 19-disk RAID-Z3 misschien wel als superieur aan een 10-disk RAID-Z2, ook al is de parity overhead lager. 3 disks uitvallen is best wel een stootje. Alleen een gemeenschappelijke oorzaak (bliksem, brand, diefstal) zou uitval van meerdere (3+) schijven mogen veroorzaken binnen korte tijd. Dus dat zou je genoeg tijd moeten geven om een gefaalde schijf te replacen voor een nieuwe.

Nadeel van mijn keuze is wel dat de huidige 10-disk RAID-Z2 vernietigd wordt. Het is een backup, dus op zich kan alles weg. Maar dan heb ik geen backup meer. Daarom maak ik mijn nieuwe 19-disk RAID-Z3 straks aan als 16-disk RAID-Z3 met 3 schijven missend. Die drie maak ik dan een tijdelijke RAID0 pool van, dus 9TB. Daar kan ik de meest belangrijke dingen eerst naartoe syncen voordat ik de RAID-Z2 pool vernietig. Pas dan maak ik de RAID-Z3 aan met 16 disks, terwijl de overige 3 disks in de tijdelijke pool zitten met een backup van de belangrijkste data. Dan begin ik met syncen van de alle data naar de 16-disk RAID-Z3 pool. Als dat voltooid is, voeg ik de 3 schijven weer toe aan de RAID-Z3 pool zodat deze volledig online bestaat uit 19 schijven.

19 schijven is een magisch getal omdat zonder de parity je op 16 uitkomt, een macht van twee. Dat is beter voor de beschikbare opslagruimte. Met large_blocks feature ingeschakeld, waardoor de recordsize van 128K naar 1024K kan stijgen, zorg je ervoor dat de disks niet 128K/16 = 8KB blokjes verstouwen, maar blokken van 1024K/16 = 64KB. Dat is vele malen sneller, maar werkt alleen voor grote bestanden. Hele kleine bestanden (ook met hulp van LZ4-compressie) kunnen met de embedded_data feature ook binnen de pointer worden opgeslagen en sparen zo veel ruimte. Want heel veel kleine files op een pool met veel disks in dezelfde vdev, kost je veel opslagruimte die je effectief niet kunt benutten; slack heet dat.

Ik heb een leuk grafiekje:



Mijn 19-disk RAID-Z3 moet je zoeken naar 16 data disks in de grafiek; want die is zonder de parity disks. Daar zie je dat een 4K optimized pool op 16 data disks het enorm goed doet, ipv bijvoorbeeld 15 data disks. Echter, dit is zonder gebruik van de large_blocks en embedded_data feature. In de praktijk is het verschil kleiner, behalve voor kleine files die net te groot zijn voor de embedded_data feature. Daarom houd ik me toch aan de regel: macht-van-twee voor het aantal data disks (totale disks minus parity disks).

Was eigenlijk benieuwd hoe jullie je ZFS NAS uitbreiden?

[ Voor 61% gewijzigd door Verwijderd op 04-09-2016 16:42 ]

[Pantagruel]

Verwijderd schreef op zondag 04 september 2016 @ 16:24:

TL;DR

Was eigenlijk benieuwd hoe jullie je ZFS NAS uitbreiden?

Ik heb er destijds (maart 2015) een tweede array bij geplaatst, de ruimte was er in de kast. Bij een toekomstige verandering wordt het wel nadenken, het betekend t verplaatsen/vervangen van het kleinste array en het is nu rik raden hoe dat zal gaan verlopen (maar dat zien ik dan wel weer).

[Verwijderd]

Of gewoon een 2e server? Waarom persé alles in één machine? Qua prijs hoef je de aanschaf van een simpel mobo/cpu/ram systeempje niet te laten; N3160 bijvoorbeeld. Als je zonder ECC kunt tenminste.

[Pantagruel]

Verwijderd schreef op maandag 05 september 2016 @ 10:57:
Of gewoon een 2e server? Waarom persé alles in één machine? Qua prijs hoef je de aanschaf van een simpel mobo/cpu/ram systeempje niet te laten; N3160 bijvoorbeeld. Als je zonder ECC kunt tenminste.

Dat is idd een optie.
De huidige setup is fysiek en hardware technisch ruim genoeg bemeten om de 2e array te omvatten dus waarom dan ook niet.
Wel of geen ECC is een overweging die ieder voor zichzelf mag maken, wat mij betreft geldt dat als je lonkt naar server grade hardware ECC er bijhoort en je de extra kosten in de rekening meeneemt.
Wellicht als HTPC is zo'n N3160 bordje bruikbaar, qua storage wellicht te beperkt (max 4x SATA of een PCIe x16 slot dat electrisch op x1 draait.

[Verwijderd]

Ga je toch de ECC route is 10G ethernet ook leuk. Ik bedoel je zit toch al in een andere price range, dan ben ik geneigd om full-out te gaan. Maar dan wel op een leuk 'koopmoment'. Bijvoorbeeld wanneer serverbordjes met 10GbE (10GBaseT) flink goedkoper worden. Laatst had ik dacht ik een bordje van tussen de 400 en 500 euro met 10G ethernet erop. Dat is al flink goedkoper dan de Xeon-D die gruwelijk sexy voor een NAS is, maar ook gruwelijk duur. De losse X540/X550 adapters van Intel blijven erg prijzig.

Dat gezegd, AMD Zen zou ook nog leuk speelgoed kunnen worden eind dit jaar. Mogelijk allemaal wat goedkoper.

[FireDrunk]

Als merk je niet zoveel uitmaakt: Kijk eens naar Chelsio, die hebben echt _hele_ goedkope 10Gb adapters (Lees: 28$ op eBay). Werken (mits je de iets recentere modellen pakt) prima onder Linux en ESXi. (BSD geen idee).

HyperBart kwam met een vrij basaal testje op ~6Gb doorvoersnelheid...

[Pantagruel]

Verwijderd schreef op maandag 05 september 2016 @ 12:41:
Ga je toch de ECC route is 10G ethernet ook leuk. Ik bedoel je zit toch al in een andere price range, dan ben ik geneigd om full-out te gaan. Maar dan wel op een leuk 'koopmoment'. Bijvoorbeeld wanneer serverbordjes met 10GbE (10GBaseT) flink goedkoper worden. Laatst had ik dacht ik een bordje van tussen de 400 en 500 euro met 10G ethernet erop. Dat is al flink goedkoper dan de Xeon-D die gruwelijk sexy voor een NAS is, maar ook gruwelijk duur. De losse X540/X550 adapters van Intel blijven erg prijzig.

Dat gezegd, AMD Zen zou ook nog leuk speelgoed kunnen worden eind dit jaar. Mogelijk allemaal wat goedkoper.

Klopt, 10GbE op termijn (mag ik de switch en ook alle kabels in t huis vervangen, nu Gbit/cat 5e) , Gbit voldoet in de thuis situatie nu nog steeds (luxe probleem zullen we maar zeggen). Eerlijk gezegd zijn er inmiddels meer wireless dan wired devices in gebruik in de huishouding dus optimaal gebruik maken van de 'line speed' is er steeds minder bij.
Leuke, sexy server hardware is en blijft kostbaar speelgoed;)

[Verwijderd]

Maar je wireless systemen zullen vooral films streamen bijvoorbeeld, maar niet zo snel bulk data heen en weer gaan slepen, zoals je wel doet tussen verschillende NAS systemen die elkaar backuppen. En eventueel naar dedicated VM hosts, etc.

Over Braswell N3160 nog: je hebt standaard 4x SATA, maar je hebt wel minimaal één keer Mini-PCIe, daar kan ik een 2x SATA/600 ASMedia kaartje voor gebruiken. En je kun teen Delock 10x SATA op de PCI-express x1 of x2 zetten. SuperMicro heeft 2 lanes op de PCI-express x4 slot. Andere bordjes hebben vaak maar één lane. Met twee lanes deel je 1GB/s voor 10 schijven. In de praktijk vaak prima, zeker voor gigabit. Zelfs één lane zou voor een instapserver helemaal prima zijn.

Delock 10x SATA kaartje werkt lekker onder BSD inmiddels. Gewoon AHCI dus native drivers, geen heatsink, geen fan, laag energieverbruik en features als TRIM werken gewoon, wat niet zomaar werkt met een SAS controller met STP (SATA Tunneling Protocol) onder BSD. Ook erg goedkoop per poort. Nadeel is wel dat je niet met Mini-SAS kabels werkt. Dus enorme kabelbrij.

Dus 4+2+10=16 disks mogelijk op een Mini-ITX Braswell systeem. Meer disks rechtvaardigt toch wel een duurder systeem. Dan is het geen instapserver meer.

N3160 heeft wel de beschikking over AES-NI, waardoor je dus encryptie kunt gebruiken. De J1900 die ik ook heb, kan maar met moeite 60-70MB/s stouwen met software encryptie, waarbij alle 4 de cores gebruikt worden. Kortom, N3160 platform vind ik best leuk als goedkoop maar schattig speelgoed.

[Pantagruel]

Verwijderd schreef op maandag 05 september 2016 @ 13:48:
Maar je wireless systemen zullen vooral films streamen bijvoorbeeld, maar niet zo snel bulk data heen en weer gaan slepen, zoals je wel doet tussen verschillende NAS systemen die elkaar backuppen. En eventueel naar dedicated VM hosts, etc.

Doorgaans wel (kids met de tablet of smartphone die x264 mkv-tjes streamen). Af en toe doet de betere helft haar foto's overzetten vanaf de smartphone op de iMac (zomervakantie 8 Gib) en dan op de server, dat duurt dan wel even.
De ESXi bak draait alles lokaal, het handje vol vm's past op een 80 Gib SSD-tje. De download vm heeft zijn eigen storage deel dat aan een HBA hangt (passthrough). De backup server hangt aan het netwerk middels de powerline , ik had me voor genomen om cat7 door de kruipruimte te trekken, maar ik krijg mijn 'atletisch gebouwde lichaam' niet veel verder dan de opening van de kruipruimte. Ook al is deze ca 50 cm hoog (zandbed tot onderzijde vloerplaten) zitten alle leidingen op ca 10 cm van t 'plafond' . Vergt t nodige graven voordat ik achter bij t huis ben belandt om onder de diverse rioleringsbuizen door te komen en vervolgens richting de garage kan oversteken. De motivatie zakte me spontaan in de schoenen .

Over Braswell N3160 nog: je hebt standaard 4x SATA, maar je hebt wel minimaal één keer Mini-PCIe, daar kan ik een 2x SATA/600 ASMedia kaartje voor gebruiken. En je kun teen Delock 10x SATA op de PCI-express x1 of x2 zetten. SuperMicro heeft 2 lanes op de PCI-express x4 slot. Andere bordjes hebben vaak maar één lane. Met twee lanes deel je 1GB/s voor 10 schijven. In de praktijk vaak prima, zeker voor gigabit. Zelfs één lane zou voor een instapserver helemaal prima zijn.

Delock 10x SATA kaartje werkt lekker onder BSD inmiddels. Gewoon AHCI dus native drivers, geen heatsink, geen fan, laag energieverbruik en features als TRIM werken gewoon, wat niet zomaar werkt met een SAS controller met STP (SATA Tunneling Protocol) onder BSD. Ook erg goedkoop per poort. Nadeel is wel dat je niet met Mini-SAS kabels werkt. Dus enorme kabelbrij.

Dus 4+2+10=16 disks mogelijk op een Mini-ITX Braswell systeem. Meer disks rechtvaardigt toch wel een duurder systeem. Dan is het geen instapserver meer.

N3160 heeft wel de beschikking over AES-NI, waardoor je dus encryptie kunt gebruiken. De J1900 die ik ook heb, kan maar met moeite 60-70MB/s stouwen met software encryptie, waarbij alle 4 de cores gebruikt worden. Kortom, N3160 platform vind ik best leuk als goedkoop maar schattig speelgoed.

Idd de N3160 is leuk als je een kleinere NAS in t vizier hebt, relatief goedkoop, compact qua behuizing en toch redelijk wat opslag potentie.

[A1AD]

O mijn god, heeft er al iemand eens een RMA naar Seagate gestuurd? Mijn 2de aangetekende poging (vanuit Belgie) is weeral terug.

Eerste poging: adres dat ik bij de RMA aanvraag heb gekregen. (ni
2de poging: Seagate koolhovenlaan 1, 1119 Schiphol-rijk (gevonden op internet..)

Iemand tips voor een 3de poging? Het terug sturen kost me al meer dan de schijf zelf, wat een drama zeg

[Pantagruel]

A1AD schreef op woensdag 7 december 2016 @ 09:56:
O mijn god, heeft er al iemand eens een RMA naar Seagate gestuurd? Mijn 2de aangetekende poging (vanuit Belgie) is weeral terug.

Eerste poging: adres dat ik bij de RMA aanvraag heb gekregen. (ni
2de poging: Seagate koolhovenlaan 1, 1119 Schiphol-rijk (gevonden op internet..)

Iemand tips voor een 3de poging? Het terug sturen kost me al meer dan de schijf zelf, wat een drama zeg

Niet recentelijk, maar in t verleden nooit problemen gehad met t adres dat op de RMA formulieren staat.

[Q]

Eindelijk InfiniBand aangesloten.

http://louwrentius.com/us...-to-point-networking.html

Performance is niet optimaal maar acceptabel. Ik ben blij met 750 MB/s over NFS.

[FireDrunk]

Q schreef op zondag 26 maart 2017 @ 00:59:
Eindelijk InfiniBand aangesloten.

http://louwrentius.com/us...-to-point-networking.html

Performance is niet optimaal maar acceptabel. Ik ben blij met 750 MB/s over NFS.

Nice! Probeer voor de grap ook eens iperf -P 4 of 10. Dat zal misschien ook nog wel iets meer performance opleveren.