Storage showcase topic - 50+ TB storage systems

[Q]

SMR schijven zijn bedoeld voor archivering. Je moet ze als TAPE zien. Prima als je ze ZFS 'formatteert' maar gebruik ze niet in een RAID, geen L2ARC en geen SLOG.

Gebruik deze dingen niet om 'live' dingen op te doen.

Dit soort schijven zijn eigenlijk gemaakt voor partijen als Backblaze of mensen die een Ceph storage cluster bouwen en dus niet aan RAID doen. Backblaze proprietary software en Ceph kunnen wel data met erasure encoding met N redundnancy opslaan over verschillende schijven (over verschillende hosts, in verschillende datacenters).

Dus RAID is dan niet nodig.

Alleen in die omgevingen heeft het zin om data op 8 TB SMR schijven te zetten en die semi-live te gebruiken.

[Dadona]

Kun je ook iets meer vertellen waarom ze niet geschikt zijn voor in een raid opstellen en waarom je ze niet met L2ARC en SLOG in moet zetten. Juist met L2ARC help je de discs waar ze het het meest nodig hebben. Sterker nog, ik zie ze als de perfecte combinatie. Een zo groot mogelijke disc qua opslagruimte, ten koste van schrijfsnelheid, en dat dan compenseren met een caching disc. Zodoende kan de archive alles rustig wegschrijven.

[Q]

Dit artikel articuleert precies waarom je geen 8 TB Archival HDs in RAID arrays wilt stoppen. Je zou bijna beweren dat ik dit artikel had gelezen voordat ik mijn rant schreef.

http://www.tomsitpro.com/...ive-hdd-review,2-822.html

De drives werken wel 'live' in object storage oplossingen omdat de drives individueel maar weinig I/O zullen zien.

Maar door de trage schrijf snelheid zou een RAIDZ array van 3 disks zo 2.3 dagen kunnen duren, en dat is nog een positieve schatting. Gedurende de rebuild, staan deze 8 TB archiverings disks gigantisch te stampen, waar ze niet voor bedoeld zijn.

Ze zijn bedoeld in een omgeving waar af en toe een kleine stroom data wordt weggeschreven of uitgelezen (dus Ceph en consorten met grotere aantallen disks).

Als stand-alone backup schijf voor thuis is het ook prima.

[ Voor 53% gewijzigd door Q op 27-10-2015 07:54 ]

[The Lord]

Q schreef op dinsdag 27 oktober 2015 @ 07:49:
...

SMR schijven kun je bij 'reads belangrijker dan writes' zondermeer in een RAID setup toepassen. Dit vereist een goed ontwerp, maar dat geldt voor elke situatie.

Onder RAID moet wel letterlijk Redundant Array of Independent Disks verstaan en niet meteen aan een 5 jaar oude hardware RAID controller denken o.i.d.

Nog ff mijn eigen ego poetsen door een quote te plaatsen:

The Lord schreef op dinsdag 11 november 2014 @ 11:27:
[...]

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.

Rekening houden met RMW kan bij veel workloads wellicht al voldoende worden ingevuld met grote stripe width over een aantal SMR schijven; 1MB over 4 schijven is tenslotte al 4MB. Als dit een sequentiele write wordt door serialization na de caching laag dan hoeft dit geen probleem voor SMR schijven te zijn.

[Q]

The Lord schreef op dinsdag 27 oktober 2015 @ 09:59:
[...]

SMR schijven kun je bij 'reads belangrijker dan writes' zondermeer in een RAID setup toepassen.

Alle optimalisaties ten spijt, zodra een disk in de RAID(Z) er mee kapt en - stel - je hebt 4 TB aan data er op staan, dan staat de boel 3-4 dagen te stampen om te rebuilden en zit je zelf met samen geknepen billen want die schijven zijn niet gemaakt om 24/7 achter elkaar te stampen.

Wat mensen zelf thuis doen moeten ze zelf weten, maar in de context van dit forum en de zelfbouw NAS systemen: ik zou het sterk afraden om 8 TB SMR schijven in een RAID setup te zetten.

[ Voor 4% gewijzigd door Q op 27-10-2015 14:40 ]

[Dadona]

Waarom toch altijd dat denken in rebuilds? Ik denk bij RAID vooral aan uptime en uitstel van executie. Dat de zaak niet meteen plat ligt.
Uiteindelijk ga ik uit van een backup, RAID is voor mij een aanvulling om net die ene sync te kunnen draaien. Dus stel je hebt een mailserver op een RAID opstelling staan. Dat je dan alle services down uitzet, een sync maakt van de data van die dag (/dat uur / ...) naar een tweede systeem.
Daarna is het even afwegen wat je wil doen. Zeker als de array al langere tijd heeft gedraaid (deels afgewaardeerd is) kom ik dichterbij het moment dat ik niet eens meer een rebuild ga overwegen. Dan vervang ik de array of bouw ik de array opnieuw op met een nieuwe disc.

[sdk1985]

Q schreef op dinsdag 27 oktober 2015 @ 07:49:

Als stand-alone backup schijf voor thuis is het ook prima.

Ik overweeg er twee in raid 1 te zetten en zo van 6 schijven naar 2 te gaan in mijn zelfbouw NAS. Raad je dat dan ook af? Echt rebuilden is dat niet maar als hij echt traag wordt dan gaat 8 TB wel even duren...

[Q]

Dadona schreef op dinsdag 27 oktober 2015 @ 17:48:
Waarom toch altijd dat denken in rebuilds? Ik denk bij RAID vooral aan uptime en uitstel van executie. Dat de zaak niet meteen plat ligt.
Uiteindelijk ga ik uit van een backup, RAID is voor mij een aanvulling om net die ene sync te kunnen draaien. Dus stel je hebt een mailserver op een RAID opstelling staan. Dat je dan alle services down uitzet, een sync maakt van de data van die dag (/dat uur / ...) naar een tweede systeem.
Daarna is het even afwegen wat je wil doen. Zeker als de array al langere tijd heeft gedraaid (deels afgewaardeerd is) kom ik dichterbij het moment dat ik niet eens meer een rebuild ga overwegen. Dan vervang ik de array of bouw ik de array opnieuw op met een nieuwe disc.

Edit, even anders verwoord.

Veel DIY NAS bouwers, zeker van grote storage, kunnen die data niet allemaal backuppen, dat is meestal een bewuste keuze en daarom is een rebuild extra belangrijk. Voor de meesten is jouw scenario niet realistisch.

RAID is helemaal geen uitstel van executie, hooguit met SMR schijven ja, maar verder niet.

De meeste mensen willen geen gedonder, gewoon disk vervangen, rebuild en en klaar.

Probeer je je eens voor te stellen dat je een 30 TB backup zou hebben en die terug moet zetten op SMR schijven.

Brrrrr.

sdk1985 schreef op dinsdag 27 oktober 2015 @ 18:26:
[...]

Ik overweeg er twee in raid 1 te zetten en zo van 6 schijven naar 2 te gaan in mijn zelfbouw NAS. Raad je dat dan ook af? Echt rebuilden is dat niet maar als hij echt traag wordt dan gaat 8 TB wel even duren...

RAID 1 of pariy raid, maakt niet veel uit voor de belasting van de schijven. Persoonlijk zou ik het niet doen. Ik zou het geld eerder in reguliere 6 TB schijven stoppen.

[ Voor 17% gewijzigd door Q op 28-10-2015 00:18 ]

[sdk1985]

Die zijn per GB alleen wel een stuk duurder. Deze Seagate Destktop HDD 5 TB schijf leek mij ook leuk voor een Raid 1 alleen hij is vrijwel nergens leverbaar (ik haal ze altijd graag fysiek in de winkel af, potbezorging hier is vaak niet echt voorzichtig): pricewatch: Seagate Desktop HDD ST5000DM000, 5TB

[ Voor 3% gewijzigd door sdk1985 op 28-10-2015 01:48 ]

[cobo]

sdk1985 schreef op woensdag 28 oktober 2015 @ 01:47:
Die zijn per GB alleen wel een stuk duurder. Deze Seagate Destktop HDD 5 TB schijf leek mij ook leuk voor een Raid 1 alleen hij is vrijwel nergens leverbaar (ik haal ze altijd graag fysiek in de winkel af, potbezorging hier is vaak niet echt voorzichtig): pricewatch: Seagate Desktop HDD ST5000DM000, 5TB

Deze interne harde schijf is via Maxict gewoon af te halen. De prijs is alleen fors duurder. Namelijk 40 euro.

[The Lord]

Q schreef op woensdag 28 oktober 2015 @ 00:14:
[...]
Edit, even anders verwoord.
...
Brrrrr.

IMO:

• Als data niet belangrijk genoeg is voor offsite back-up dan is beschikbaarheid blijkbaar van minder belang. Ergo, trage data tijdens rebuild niet onoverkomelijk.
• DIY NAS bouwers die "gewoon een disk willen vervangen" kunnen het beste een 'standaard' oplossing aanschaffen. Al dan niet een Synology/o.i.d. met schijven van de Hardware Compatibility List of een 'best buy guide' volgen.
• 30TB aan data naar een SMR RAID sturen hoeft niet significant langer te duren dan naar b.v. een PMR RAID. Mits het ontwerp juist is. Ontwerp je PMR RAID verkeerd (ben ik meerdere malen tegen gekomen) dan zal dit bij 30TB write significant slechter presteren dan SMR RAID met een goed ontwerp.

Wat ik bij veel tests zie is dat SMR schijven in een setup worden gebruikt die ontworpen is voor niet SMR schijven. Los van het feit dat SMR bij voorbaat ongeschikt is om direct random writes met kleine block size met een flinke queue te verwerken.
Op het moment dat in een review een aantal SMR schijven in een huis-tuin&keuken NAS wordt gestopt gaat het al fout. Gek dat het niet performed.
En dan de schijf eruit, wachten op degraded state en dan de volle schijf terug stoppen voor een rebuild komt dicht bij het stomste gebruik voor een SMR schijf.

Op het moment dat je een rebuild uitvoert met een lege disk i.c.m. een FS dat gebruik maakt van de juiste stripe width, fatsoenlijke cache, log en data serialized dan zal het ongetwijfeld net zo snel al dan niet sneller gaan dan op die geteste NAS met HCL schijven.

[sdk1985]

cobo schreef op woensdag 28 oktober 2015 @ 09:04:
[...]


Deze interne harde schijf is via Maxict gewoon af te halen. De prijs is alleen fors duurder. Namelijk 40 euro.

MaxICT heeft al jaren een 2 sterrenrating dus die neem ik eigenlijk niet serieus. Wordt alleen waarschijnlijk offtopic, alhoewel ik ook over de 20 TB ga ik als ik nog schijven bijplaats .

[ Voor 14% gewijzigd door sdk1985 op 28-10-2015 14:52 ]

[Q]

The Lord schreef op woensdag 28 oktober 2015 @ 11:28:
[...]

IMO:
[ul]• Als data niet belangrijk genoeg is voor offsite back-up dan is beschikbaarheid blijkbaar van minder belang. Ergo, trage data tijdens rebuild niet onoverkomelijk.

Je houdt helemaal geen rekening met de context die ik net beschreef, je gaat te kort door de bocht.

Het is gewoon financieel niet haalbaar om 30 TB+ aan data ook nog eens te backuppen naar een 2e systeem of oplossing.

Er zit wel een hoop werk in het verzamelen van de data en het zou dus voor de meesten hier erg jammer zijn als je dat opnieuw moet doen. Het is geen hals zaak, zoals met de foto's van je kinderen, maar zonde is het wel.

Binnen deze context is het dus prima om kwaliteitscomponenten te kopen, RAIDZ2/3 te gebruiken en is het ook verstandiger om je geld te stoppen in schijven die niet zo fragiel zijn.

• DIY NAS bouwers die "gewoon een disk willen vervangen" kunnen het beste een 'standaard' oplossing aanschaffen. Al dan niet een Synology/o.i.d. met schijven van de Hardware Compatibility List of een 'best buy guide' volgen.

Dat is veel te ongenuanceerd en dat zegt wat want ik ben niet echt mr. nuance.

Een falende disk is niets bijzonders. Je moet niet een hele backup/restore operatie moeten doen met zoveel data, dat gaat weken kosten, alleen maar gedonder en risico's.

Wij bouwen hier een oplossing waarbij je gewoon even de disk vervangt.

• 30TB aan data naar een SMR RAID sturen hoeft niet significant langer te duren dan naar b.v. een PMR RAID. Mits het ontwerp juist is. Ontwerp je PMR RAID verkeerd (ben ik meerdere malen tegen gekomen) dan zal dit bij 30TB write significant slechter presteren dan SMR RAID met een goed ontwerp.[/ul]
Wat ik bij veel tests zie is dat SMR schijven in een setup worden gebruikt die ontworpen is voor niet SMR schijven. Los van het feit dat SMR bij voorbaat ongeschikt is om direct random writes met kleine block size met een flinke queue te verwerken.
Op het moment dat in een review een aantal SMR schijven in een huis-tuin&keuken NAS wordt gestopt gaat het al fout. Gek dat het niet performed.
En dan de schijf eruit, wachten op degraded state en dan de volle schijf terug stoppen voor een rebuild komt dicht bij het stomste gebruik voor een SMR schijf.

Op het moment dat je een rebuild uitvoert met een lege disk i.c.m. een FS dat gebruik maakt van de juiste stripe width, fatsoenlijke cache, log en data serialized dan zal het ongetwijfeld net zo snel al dan niet sneller gaan dan op die geteste NAS met HCL schijven.

Je hebt het over een 'goed' ontwerp, maar je beschrijft niet wat dat 'goede ontwerp' precies inhoudt. Ik denk iets met ZFS, maar ik ben wel benieuwd, en sceptisch, dat ook.

EDIT: bedoel je dit?

Rekening houden met RMW kan bij veel workloads wellicht al voldoende worden ingevuld met grote stripe width over een aantal SMR schijven; 1MB over 4 schijven is tenslotte al 4MB. Als dit een sequentiële write wordt door serialization na de caching laag dan hoeft dit geen probleem voor SMR schijven te zijn.

EDIT: Hoe zet je zoiets op met ZFS dan? Bedoel je large_blocks support?

Bovendien kunnen de SMR schijven vaak maar met rond de 30MB/s schrijven max, en is deze performance enorm variabel, wat het rebuild proces alleen maar vertraagd.

En je ontkomt er fundamenteel niet aan dat je schijven bij een rebuild dus gewoon even 24/7 staan te 'stampen' en dat is precies waar die SMR schijven niet voor zijn bedoeld.

Zoals ik het lees zijn SMR schijven bedoeld in een omgeving waar ze af en toe kleine stroompjes data krijgen gevoed, of dat ze kleinere hoeveelheden gedurende een korte tijd moeten aanleveren, dan zijn ze het beste in hun element.

[ Voor 11% gewijzigd door Q op 28-10-2015 20:11 ]

[The Lord]

Q schreef op woensdag 28 oktober 2015 @ 20:06:
[...]
Het is gewoon financieel niet haalbaar om 30 TB+ aan data ook nog eens te backuppen naar een 2e systeem of oplossing.

Binnen deze context is het dus prima om kwaliteitscomponenten te kopen, RAIDZ2/3 te gebruiken en is het ook verstandiger om je geld te stoppen in schijven die niet zo fragiel zijn.

Nou ja, dan bedoelen we eigenlijk hetzelfde.
Is de data niet belangrijk genoeg voor een (offsite) back-up dan kies je een (andere) trade-off.

Wil je een beperktere impact op je beschikbaarheid in geval van een falende schijf of ligt de balans R/W anders dan 90%/10% (grofweg; veel writes kan in specifieke scenario's nog steeds) dan kies je al snel voor PMR schijven, maar kun je minder GB/€ opslaan.

Wil je zoveel mogelijk data opslaan, ligt de R/W balans wel rond 90%/10% of een ander passend scenario dan kun je SMR schijven toepassen.

Een falende disk is niets bijzonders. Je moet niet een hele backup/restore operatie moeten doen met zoveel data, dat gaat weken kosten, alleen maar gedonder en risico's.

Relatief gezien is een falende disk wel vrij bijzonder (MTBF). In de praktijk ben ik een aantal SAN's/Nassen tegengekomen waarbij de leverancier van bepaalde schijven elke week dozen met vervangende exemplaren leverde.
Om de één of andere reden waren de prestaties onder de maat op deze dure apparaten(Gek hoor als ze vrijwel continue in degraded state draaien...).

Mijn punt is dat dit zeker geen weken hoeft te kosten.

De mijne ook.

Wij bouwen hier een oplossing waarbij je gewoon even de disk vervangt.

Nee, geen mr. nuance.
Ik denk niet dat iedereen het in die zin doet; 20+TB storage systems is een wat wijd begrip. Ik heb zelf mijn DVD/BR rips op een disk pool staan zonder verdere redundantie. Vullen gaat per disk, geen striping over de disks. Gaat er 1 kapot of raakt er een gedeelte corrupt dan kan ik, als ik zin heb, de verloren gegane films weer opnieuw rippen.

Je hebt het over een 'goed' ontwerp, maar je beschrijft niet wat dat 'goede ontwerp' precies inhoudt. Ik denk iets met ZFS, maar ik ben wel benieuwd, en sceptisch, dat ook.

EDIT: bedoel je dit?

Een goed ontwerp in algemene zin van het woord; zonder direct aan een bepaald FS te denken. Dus block/page size van applicatie, block/stripe size van FS en block/stripe width/interleave van storage virtualisatie als eerste. Dan de keuze/implementatie van storage virtualisatie, FS en als laatste schijven en alignment.

Simpel voorbeeld films: grote bestanden (applicaties), sequentieel WORM patroon, max block/stripe in FS, grootste block/stripe width over zoveel mogelijke spindles (meestal financieel plaatje) en/of eventueel cache toevoegen. Met thin provisioned volume erop kun je best SMR gebruiken.

EDIT: Hoe zet je zoiets op met ZFS dan? Bedoel je large_blocks support?

Geen idee; daar huur ik altijd de specifieke expertise voor in. Wat niet altijd meevalt; bij verschillende dure Enterprise oplossingen was de expert van de leverancier niet zo heel erg een expert. Gaat soms zo ver dat het verschil tussen bruto en netto IOps niet bekend is.

Voor de lol heb ik e.e.a. wel met ReFS, NTFS en storage spaces getest.

Bovendien kunnen de SMR schijven vaak maar met rond de 30MB/s schrijven max, en is deze performance enorm variabel, wat het rebuild proces alleen maar vertraagd.

Of 180MB/s sequentieel op een lege schijf. Hangt van het patroon af; een PMR schijf haalt die 30MB/s ook niet bij een 'niet optimaal' IO patroon.
Zoals ik al als voorbeeld schreef: een standaard NAS vullen met SMR schijven, hier een parity volume op plaatsen, set degraden en dan de niet lege SMR schijf terug plaatsen voor een rebuild is gewoonweg dom. Dan dwing je de schijf een volledige read before write uit te voeren op de overlappende shingles. En dat zijn dus vrijwel meteen alle datablokken op de schijf. En dat hoogstwaarschijnlijk nog eens met 'verkeerde' block sizes.

En je ontkomt er fundamenteel niet aan dat je schijven bij een rebuild dus gewoon even 24/7 staan te 'stampen' en dat is precies waar die SMR schijven niet voor zijn bedoeld.

Mijn punt: zolang de schijf leeg is en er een redelijk optimaal data patroon is (grote blokken sequentiële writes) tijdens de rebuild zul je geen significant verschil zien met PMR schijven.

Zoals ik het lees zijn SMR schijven bedoeld in een omgeving waar ze af en toe kleine stroompjes data krijgen gevoed, of dat ze kleinere hoeveelheden gedurende een korte tijd moeten aanleveren, dan zijn ze het beste in hun element.

SMR schijven houden inderdaad absoluut niet van veel kleine random writes. Bij niet hoog volume grote sequentiële writes doen ze niet onder voor PMR schijven.

[sdk1985]

Ik volg de discussie omdat ik nog steeds mijn NAS moet upgraden .

Volgens Reddit zouden die schijven nadat de buffer vol is terugvallen naar circa 10MB/s. In dat geval duurt het meer dan 200 uur om 8 TB te vullen (36000 MB/uur). Dat is 9 dagen. Ik heb echter een review gevonden die precies dat tests via een Raid 1 setup en die kwamen op 57 uur (een normale deed 19 uur): http://www.storagereview.com/seagate_archive_hdd_review_8tb



Echter als ik de specificaties vergelijk met bijvoorbeeld de Desktop serie dan zijn de power on hours 4x groter met gelijke load cycles en de TB /year stijgt van 55 naar 180. Dat zou impliceren dat deze 57 uur toch geen probleem is (behalve dat het lang duurt). Het is natuurlijk niet alsof dat elke dag gaat voorkomen. Of mis ik iets?

[Pantagruel]

sdk1985 schreef op donderdag 29 oktober 2015 @ 14:55:
Ik volg de discussie omdat ik nog steeds mijn NAS moet upgraden .

Volgens Reddit zouden die schijven nadat de buffer vol is terugvallen naar circa 10MB/s. In dat geval duurt het meer dan 200 uur om 8 TB te vullen (36000 MB/uur). Dat is 9 dagen. Ik heb echter een review gevonden die precies dat tests via een Raid 1 setup en die kwamen op 57 uur (een normale deed 19 uur): http://www.storagereview.com/seagate_archive_hdd_review_8tb

[afbeelding]

Echter als ik de specificaties vergelijk met bijvoorbeeld de Desktop serie dan zijn de power on hours 4x groter met gelijke load cycles en de TB /year stijgt van 55 naar 180. Dat zou impliceren dat deze 57 uur toch geen probleem is (behalve dat het lang duurt). Het is natuurlijk niet alsof dat elke dag gaat voorkomen. Of mis ik iets?

Do NOT fear, a better 8 TB drive is here! Seagate Announces The World’s First 8TB Surveillance HDD

Spec's:

code:

Specifications:

    Capacity: 8TB
    Cache: 256MB
    Bytes per Sector: 4096
    Performance
        R/V (Rotational Vibration) Sensor
        Drive Bays Supported: 8+
        Cameras Supported: Up to 64
        Max Sustainable Transfer Rate: 230MB/s
    +Rescue Data Recovery Service: 3-Year Option With +Rescue Model
    Voltage
        Voltage Tolerance, Inc. Noise (5V): ±5%
        Voltage Tolerance, Inc. Noise (12V): ±10%
    Power Management
        Startup Power (12V, A): 1.8
        Average Operating Power: 9W
        Idle Average: 7.6W
        Standby Mode: 0.6W
        Sleep Mode: 0.6W
    Environmental/Temperature
        Operating (ambient, min): 5°C
        Operating (drive case, max): 60°C
        Nonoperating (ambient, min): -40°C
        Nonoperating (ambient, max): 70°C
    Reliability
        Load/Unload Cycles: 300,000
        Nonrecoverable Read Errors per Bits Read, Max: 1 per 10E15
        Mean Time Between Failures Power-On Hours: 1M
        Warranty, Limited (years): 3
    Physical
        Height: 1.028in (26.11mm)
        Width: 4.010in (101.85mm)
        Depth: 5.878in (147mm)
        Typical Weight: 1.72lb (780g)

[Q]

Pantagruel schreef op donderdag 29 oktober 2015 @ 16:10:
[...]


Do NOT fear, a better 8 TB drive is here! [

Nonrecoverable Read Errors per Bits Read, Max: 1 per 10E15



Ben benieuwd. Met name ook naar de prijs...

[ Voor 5% gewijzigd door Q op 29-10-2015 22:48 ]

[rikadoo]

Prijs word rond de 385 dollar.

[Dadona]

Q schreef op woensdag 28 oktober 2015 @ 20:06:
[...]
Het is gewoon financieel niet haalbaar om 30 TB+ aan data ook nog eens te backuppen naar een 2e systeem of oplossing.

...

Binnen deze context is het dus prima om kwaliteitscomponenten te kopen, RAIDZ2/3 te gebruiken en is het ook verstandiger om je geld te stoppen in schijven die niet zo fragiel zijn.

Nu weet ik niet wat je precies onder kwaliteitscomponenten verstaat. Ik zou er persoonlijk geen Western Digital Green schijven onder verstaan, maar qua prijs zijn ze eigenlijk zelfs in het voordeel van jouw argument (en voor mijn verhaal vrijwel ideaal).
Ik ben persoonlijk wel gecharmeerd van het Backblaze idee, maak een systeem redundant. Feitelijk gaan ze juist voor relatieve simpele setups, zonder fancy hardware, besparen zodoende geld uit om vervolgens feitelijk betere redundantie te krijgen.
Even puur de discs:

#	Product	Prijs	Subtotaal
6	Seagate Archive HDD v2 ST8000AS0002, 8TB	€ 225,-	€ 1.350,-
Totaal	€ 1.350,-

#	Product	Prijs	Subtotaal
6	WD Green HDD, 6TB	€ 232,50	€ 1.395,-
Totaal	€ 1.395,-

Het idee zou zijn om de Archive schijven in twee opstellingen met drie JBODs op te stellen. De Greens zou ik in RAIDZ2 / RAID6 zetten. De RAIDZ2 zou jou voorkeur hebben vermoed ik. Je ziet dat de discs dan voor 24TB op dezelfde prijs uitkomen.
Nu plaats jij dan een kwalitatief betere spullen bij die Green setup. (Seasonic uit de X serie (geen G), moederbord uit het midden segment, goede koeling, ..) Bij de Archive setups zou ik echter voor een main en fallback gaan. Een systeem dat gewoon de taken net zo goed als de Green setup aankan (maar dan met een G Seasonic of een Be Quiet voeding) en dan een simpele tweede voor als het fout gaat (langzamere proc, ..whatever).

Nu vind ik het helemaal prima dat jij voor één high quality setup gaat, maar twee goedkopere setups kunnen ook met 24TB nog een valide optie zijn. Zeker als je bedenkt dat je dan misschien nog wel meer gebruikelijke problemen afvangt. Zoals een fout door de gebruiker.
En voor het geval je het gaat opzoeken, ja, ik was van die ene setup. Maar ik merkte gewoon dat ik met die ene setup veel meer op mijn hoede moest zijn en blijven. Als ik terugkijk ben ik meer data kwijtgeraakt met fouten in configuraties dan met een schijfuitval. Maar bovenal ben ik veel geruster met twee setups dan met die ene, ik kan zelf meer permitteren. Uiteindelijk ben ik nog wel de grootste bedreiging voor mijn data, misschien ook wel omdat ik niet 24/7 ermee bezig ben. ('s Avonds thuiskomen, even snel wat willen regelen, dat werk.)

[Q]

Tja, ieders keuze en budget. In jouw context geef ik je gelijk dat je 2 systemen neerzet of neer zou zetten.
Omdat het toch om een backup systeem gaat zou je kunnen kiezen om de extreem lange rebuild tijd voor lief te nemen.

[The Lord]

sdk1985 schreef op donderdag 29 oktober 2015 @ 14:55:
Volgens Reddit zouden die schijven nadat de buffer vol is terugvallen naar circa 10MB/s. In dat geval duurt het meer dan 200 uur om 8 TB te vullen (36000 MB/uur). Dat is 9 dagen. Ik heb echter een review gevonden die precies dat tests via een Raid 1 setup en die kwamen op 57 uur (een normale deed 19 uur): http://www.storagereview.com/seagate_archive_hdd_review_8tb

Daar trekken ze ook de disk eruit en stoppen de beschreven disk weer terug. Dan wordt de schijf gedwongen zijn read before write op elke overlappende track uit te voeren. Ze zouden het met een disk moeten proberen die is verteld dat ie leeg is.

Echter als ik de specificaties vergelijk met bijvoorbeeld de Desktop serie dan zijn de power on hours 4x groter met gelijke load cycles en de TB /year stijgt van 55 naar 180. Dat zou impliceren dat deze 57 uur toch geen probleem is (behalve dat het lang duurt). Het is natuurlijk niet alsof dat elke dag gaat voorkomen. Of mis ik iets?

Dat is precies wat geïmpliceerd wordt. Praktisch gezien hoop ik dat BackBlaze met deze schijven aan de slag is en erover gaat rapporteren.

rikadoo schreef op donderdag 29 oktober 2015 @ 22:59:
Prijs word rond de 385 dollar.

Hmm, dat is een behoorlijke €/GB. Voor 'onze kleine Tweaker' oplossingen denk ik niet dat dat een interessant totale kosten per opslag plaatje oplevert. Tenzij de prijs snel wat naar beneden gaat.

[sdk1985]

The Lord schreef op zaterdag 31 oktober 2015 @ 14:59:

Dat is precies wat geïmpliceerd wordt. Praktisch gezien hoop ik dat BackBlaze met deze schijven aan de slag is en erover gaat rapporteren.

[...]

Hmm, dat is een behoorlijke €/GB. Voor 'onze kleine Tweaker' oplossingen denk ik niet dat dat een interessant totale kosten per opslag plaatje oplevert. Tenzij de prijs snel wat naar beneden gaat.

Blackblaze vindt ik zo'n onzin.. Die pakken schijven met een power on van maximaal 1/3e jaar en die gebruiken ze vervolgens 24/7. Vervolgens publiceren ze dat er schijven stuk gaan. Goh dat hadden we niet aan zien komen... Het blijf een mechanisch product. Wat Blackblaze doet staat volledig los van de "realiteit" zoals ik een schijf zou gebruiken.

Hardware.fr deed het wel leuk maar daar hoor je helaas niets meer van.

edit: Ze doen het nog wel!

19/05/2015:

- Toshiba 1,15%
- Seagate 1,44% (contre 1,65%)
- Western 1,55% (contre 1,44%)
- Samsung 2,24% (contre 1,30%)
- Hitachi 2,40% (contre 3,45%)

....

3 To :

- 3,40% Toshiba DT01ACA300
- 2,78% WD SE WD3000F9YZ
- 1,49% WD Red WD30EFRX
- 1,36% Seagate Barracuda 7200.14 ST3000DM001
- 1,31% Seagate Surveillance ST3000VX000
- 1,30% WD Green WD30EZRX
- 1,18% Seagate NAS HDD ST3000VN000
- 0,00% Seagate Enterprise Value ST3000NC002

4 To :

- 2,93% WD Green WD40EZRX
- 1,45% WD Red WD40EFRX
- 1,18% WD Black WD4003FZEX
- 1,08% Seagate NAS HDD ST4000VN000
- 1,08% Seagate SSHD ST4000DX001/
- 0,80% Seagate Desktop HDD.15 ST4000DM000
- 0,50% HGST Deskstar 7K4000 H3IK40003272SE
- 0,00% HGST Deskstar NAS 0S03665
- 0,00% Seagate Constellation ES ST4000NM0033

Wat was dat nou over de WD Green serie die kwalitatief beter zou zijn .

Dit zijn overigens percentages van het aantal schijven dat binnen de garantie terug komt bij een grote retailer. Dus de disclaimer is dat het niet alleen defecten hoeven zijn. Er is echter natuurlijk geen reden om aan te namen dat iemand met een WD sneller schijven gaat terug sturen dan iemand met een Hitachi. In het verleden zijn er daar ook weleens nieuwe 3TB schijven met 15% geweest dus het is een goede indicatie om een probleem serie op te sporen.

Overigens gaan bij mij überhaupt zelden schijven kapot (*afkloppen*). De laatste was een F3 500 GB die dit jaar met errors aan kwam. Die heb ik preventief vervangen voor een Seagate.Tot heden is er nog geen Seagate 7200.14 met problemen (Ik heb er 5; 3x 3 TB en 2x 1 TB). Dus de realiteit bij blackblaze is in mijn kleine populatie gelukkig niet mijn realiteit. Totaal heb ik een schijf of 14 ofzo (heb ook andere type's en merken).

[ Voor 51% gewijzigd door sdk1985 op 31-10-2015 17:27 ]

[Stampertjen]

Met dat ik op het forum aan het zoeken was naar ervaring met de WD Green 6TB of de Seagate Archive 8TB kwam ik op dit topic uit

Man man de storage van sommige hier is echt En dan verklaren sommige in mijn omgeving me al zot met mijn ITX systeempje in de living van 21TB

[thalantis]

ik moet zeggen dat er bij mij ook weinig schijven uitvallen (ook afkloppen)

20 x 3TB Hitachi Deskstar_7K3000
24 x 2TB Samsung HD204ui en HD203WI
4 x 4TB WD40EZRX

nu staan ze niet 24/7 aan maar de samsung schijven zijn aardig op leeftijd (2009-2010)

[Q]

Van mijn 1 TB schijven van Samsung, de befaamde en gevreesde F1 is er nog geen een echt gesneuveld, hooguit wat recovered sectors. Spul komt uit 2008 ofzo.

Ik heb bijzonder weinig schijfuitval.

Maar ik maak ook weinig branduren: de servers staan meestal uit.

[Hakker]

oh nee mijn F1's zijn gesneuveld maar dat kom omdat ik ze ook flink op hun lazer heb gegeven door als download en parity dingen te gebruiken. maar ik heb WD greens gewoon in een pool draaien. Niks aan de hand als je wdidle3 maar gebruik want anders zijn ze denk ik wel snel gaar in een raid setup.

[HyperBart]

Hakker schreef op dinsdag 03 november 2015 @ 14:51:
oh nee mijn F1's zijn gesneuveld maar dat kom omdat ik ze ook flink op hun lazer heb gegeven door als download en parity dingen te gebruiken

Daarvoor heb ik nu een 840 EVO van 500GB

Benieuwd hoe die het gaat uithouden maar met ZFS weet ik snel wanneer het echt hard bergaf gaat.

[Pantagruel]

HyperBart schreef op zaterdag 26 december 2015 @ 23:34:
[...]

Daarvoor heb ik nu een 840 EVO van 500GB

Benieuwd hoe die het gaat uithouden maar met ZFS weet ik snel wanneer het echt hard bergaf gaat.

Dat is op zich een goeie, ik merk dat de 128GB (M4) soms te krap is voor een fikse dl en een rondje par/rar dat al loopt.

[HyperBart]

Pantagruel schreef op donderdag 07 januari 2016 @ 17:06:
[...]


Dat is op zich een goeie, ik merk dat de 128GB (M4) soms te krap is voor een fikse dl en een rondje par/rar dat al loopt.

Inderdaad, er zijn een aantal voordelen die ik vooral belangrijk vond:

Een download zorgt niet onmiddellijk voor een spin up
Als een download faalt, helemaal geen spin up tot er een nieuwe download binnenkomt
Tijdens het downloaden geen hoger verbruik omdat de disks down blijven. Als je dus een heel seizoen van een serie binnen haalt dan blijven de disks in spindown tot SB/SRR de moves doen.
Doorgaans worden series rond hetzelfde uur beschikbaar dus dan queue hij alles op SSD en periodiek gaat SB/SRR de move doen en dan doe je ineens een hele rits aan episodes.

[ Voor 90% gewijzigd door HyperBart op 11-01-2016 12:35 ]

[Pantagruel]

HyperBart schreef op maandag 11 januari 2016 @ 12:27:
[...]


Inderdaad, er zijn een aantal voordelen die ik vooral belangrijk vond:

Een download zorgt niet onmiddellijk voor een spin up
Als een download faalt, helemaal geen spin up tot er een nieuwe download binnenkomt
Tijdens het downloaden geen hoger verbruik omdat de disks down blijven. Als je dus een heel seizoen van een serie binnen haalt dan blijven de disks in spindown tot SB/SRR de moves doen.
Doorgaans worden series rond hetzelfde uur beschikbaar dus dan queue hij alles op SSD en periodiek gaat SB/SRR de move doen en dan doe je ineens een hele rits aan episodes.

Klopt, daarnaast scheelt t flink wat 'wear and tear' voor de spindles en de ssd lag min of meer ongebruikt rond te slinger (I know shame on me). Ik had gedacht hem in een nuc te zetten als HTPC, maar de betere helft heeft me een RPI 2B cadeau gedaan onder de kerstboom. Die ligt inmiddels in t TV meubel en OpenElec neemt de honneurs waar.

[HyperBart]

Pantagruel schreef op maandag 11 januari 2016 @ 14:43:
[...]


Klopt, daarnaast scheelt t flink wat 'wear and tear' voor de spindles

Mwoah pas op, je verplaatst die wear and tear wel naar de SSD natuurlijk, en het tikt flink aan hoor.

Ik heb ooit eens een hdparm gerund (maar dat commando deed wat rare dingen waardoor SMART in de war geraakte) en daar kwam uit dat ik ongeveer al een 41TB written had, dat kan al tellen

[sdk1985]

Ik heb een gevreesde Seagate Archive HDD 8 TB aangeschaft. Op die manier is het wel erg makkelijk om in de 20+ TB te komen .

Valt op dat hij gewoon met 102 MB/s vult (gigabit). Gooi er momenteel batches van 500 GB op. Ik vermoed dat hij pas bij 33% vulling overschakelt op SMR. Over een paar honderd GB weet ik dat zeker.

[FireDrunk]

Ik denk dat die schijf gewoon ondanks SMR vrolijk zijn hele LBA size lang > 100MB/s doet...

SMR is niet traag voor sequentieel (lezen en) schrijven, alleen voor random (lezen en) schrijven.

[sdk1985]

Volgen reddit zou de schijf een 20 GB cache hebben die op de achtergrond wordt weggeschreven. Tot heden nog niet gemerkt. Zit nu op 2.34 TB. Duurt nog wel een paar uur voor ik wat voller zit.

Update: Gisteren 50% vol gekregen. Geen schokkende verschillen in Crystaldisk mark. Van 199/194 naar 187/186. Ik wilde zeggen hypothese ontkracht maar dat zou dan die 20 GB cache nog kunnen zijn. Ik zal nog even kijken wat er gebeurd als ik nu een bestand van 34GB over zet. Ik had een windows tool die precies kon meten wat de snelheden waren maar ben de naam vergeten... RichCopy.

Met Windows zelf 34 GB (direct na elkaar):
Run1: start 184 MB/s eind: 159 MB/s
Run2: start 118 MB/s, eind: 148 MB/s

Meldingen van inzakken naar 10-50 MB/s is voorlopig dus total niet aan de orde. Dit is meer dan snel genoeg voor mijn NAS.

Tot nu toe ben ik erg onder de indruk van de schijf. Ik ben nog wat tests aan het doen maar hij wint het op veel vlakken van de 7200.14.

[ Voor 83% gewijzigd door sdk1985 op 28-01-2016 21:55 ]

[thof]

Goed nieuws trouwens, Ri-Vier gaat rond mei toch weer cases verkopen. Erg benieuwd naar wat het exacte aanbod gaat worden. Ook wel toe aan een nieuwe storage build.

We will start selling new cases soon (around May2016). What is on the website you can order as that is on stock.
We apologize for the inconvenience.

https://ri-vier.eu/

[jacovn]

Er staat nu july 2016.
Ik ga maar een 2e hands ophalen zondag. Norco eruit..

[Zebravink]

Zo bedroefend gesteld met je Norco dan dat je zelfs een tweedehands als vervanger neemt??

[ Voor 8% gewijzigd door Zebravink op 13-02-2016 09:09 ]

[jacovn]

Die norco werkt prima nu. Maar de rivier case is beter voor koeler van de hdd's.
Meer gaten in het front van de disk lade, of hoe je dat ding noemt.
Met lage doorvoer fans (geen stofzuiger nivo fans) koelt die rivier beter bij mij.

Dus het is voorkeur voor stiller..

[Q]

Mijn ri-vier case is bijna fluister stil, de airflow is 20x beter dan mijn 7 jaar oude norco 20 disk chassis. De norco maakt een rotlawaai.
Fluister stil lukt echter alleen bij mij met custom script dat via linux de fans aanstuurt op basis van de disk temperatuur.

[ Voor 6% gewijzigd door Q op 15-02-2016 08:33 ]

[Zebravink]

Hier is de Norco 4224 voorzien van Noiseblocker Blacksilentfan ventilatoren. Zowel achter de backplanes als aan de achterzijde van de server, ook fluisterstil.

[jacovn]

Hm. Fluisterstil kan ik het niet noemen, maar het staat in een ruimte die 55dB van buiten naar binnen dempt, dus dan valt alles wat geluid maakt op.

Ik heb noctua fans in de servers. In deze ri-vier kast komen 140 mm noctua fans met een pwm regelaar.

[-Venom-]

Zitten jullie in dezelfde kamer als waar de servers staan? Mijn Norco is ook voorzien van een stel stillere fan's voor wat minder lawaai maar om het ding nu stil te noemen.....

Maar ik zit er dan (gelukkig) ook niet naast

[jacovn]

Ja staat in mijn ht ruimte. Copieer nu wat ik wil zien naar qnap silent nas met een ssd: totaal stil.
Ik hoor de hdd's boven de fans uitkomen overigens. Ik kan de helft van de hdds in spindown zetten omdat er 2 pools in zitten.

[Zebravink]

Metertje afstand van m'n bureau. Hoor hem eigenlijk niet behoudens een klein beetje zuigen cq. blazen.

Ruimtetemperatuur is ongeveer 18 graden, temperatuur hd's tussen de 30 en 36 graden volgens Stablebit Scanner.

[Q]

Ik heb er zelf een apparte ruimte voor, de video in mijn artikel over mijn nas laat mooi het verschil horen (zie signature).

[thalantis]

thalantis schreef op dinsdag 17 september 2013 @ 16:59:
Lang verwachte update van mijn kant

System specifications
Component	Value
Case	Norco 4224 4U
CPU	Intel Core i7 960 @ stock
RAM	Corsair 6x2GB, DDR3, PC12800, CL9, XMS3
Motherboard	Asus Sabertooth X58
Operating system	Windows Server 2012
Controller	Areca 1880ix-24 24 poorten sata
Hard drive	20 x 3TB Hitachi Deskstar_7K3000
SSD	OCZ Vertex 2 SATA II 2.5" SSD 60GB
RAID array configuration	Boot: 1x 60 GB SSD and 20 x 3 TB RAID 6 ( 60 TB storage ) + 4 x 4TB RAID 5 ( 12 TB Storage)
Netto storage capacity	60 TB
Network	Intel X520-T2 10Gb 10GbE Base-T Dual Port PCI-E Network NIC Card E10G42BT FH
Filesystem	NTFS
Idle power usage	~190 Watt
Cpu Cooling	Corsair H80i cpu koeling
Powerswitch	ip power 9258
Voeding	Corsair ATX 850W 24P
Videokaart	Ati Radeon X550
Functie	Backup Server

Bovenstaande server is mijn backup server, ik gebruik deze server als backup van mijn main server.

Server draait windows 2012 , de 20x schijven staan in raid 6.

De asus sabertooth komt uit mijn main server aangezien het mainboard van mijn backup server is overleden, dit was een 5 jaar oude asus p5n-t socket 775 moederbord.

De stroom kan ik ook regelen van afstand met een ip power 9258.

Ik heb in de 4U kast een fan wall met 3x noctua pf12 fans en achterop 2x 80 mm noctua fans, dan heb ik in de boven plaat nog 1x noctua pf12 die warme lucht de kast uit blaast en de koeler van de corsair h80i waterkoeling zit ook aan de bovenplaat vast, kon hem nergens anders niet kwijt.

[afbeelding]
[afbeelding]
[afbeelding]

System specifications
Component	Value
Case	Rivier 24bay storage RV4324-03A
CPU	Intel Core i5 4570S @ stock
RAM	Corsair XMS3 - Geheugen - 16 GB : 2 x 8 GB
Motherboard	Asus SABERTOOTH Z87
Operating system	Windows Server 2012
Controller	Areca 1882ix-24 24 poorten sata
Hard drive	24 x 2TB Samsung HD204ui en HD203WI
SSD	OCZ vertex-2 SSD 60GB
RAID array configuration	Boot: 1x 60 GB SSD and 24 x 2 TB RAID 6 ( 48 TB storage ) plus 4x 5 TB raid 5 (15 TB Storage) via SFF-8088
Netto storage capacity	54 TB
Network	Intel X520-T2 10Gb 10GbE Base-T Dual Port PCI-E Network NIC Card E10G42BT FH
Filesystem	NTFS
Idle power usage	~ 105 Watt
Cpu Cooling	Corsair H80i cpu koeling
Powerswtich	ip power 9258
Voeding	Corsair ATX 850W 24P
Videokaart	Matrox Millennium G550 PCIe
Functie	Main Server

Bovenstaande server is mijn main server, ik gebruik deze server als mijn main server, voor opslag van van alles en nog wat.

Server draait windows 2012 , de 24x schijven staan in raid 6 + 4 schijven in raid 5

De asus sabertooth heb ik nieuw besteld voor mijn main server aangezien het mainboard van mijn backup server is overleden, dit was een 5 jaar oude asus p5n-t socket 755 moederbord.

De stroom kan ik ook regelen van afstand met een ip power 9258.

Ik heb in de 4U kast een fan wall met 3x noctua pf12 fans en achterop 2x 80 mm noctua fans, de koeler van de corsair h80i waterkoeling zit ook aan de bovenplaat vast, kon hem ergens anders niet kwijt.

Deze rivier kast vervangt mijn lian-li cube

[afbeelding]
[afbeelding]
[afbeelding]
[afbeelding]

De dual netwerk kaarten zitten verbonden via een hp switch (HP ProCurve 1810G - 8 GE, P.1.17, eCos-2.0)
Deze dual poorten zitten via de standaard windows server 2012 teaming geconfigureerd met lacp op de switch heb ik hiervoor de poorten in trunking gezet.

Beide raid kaarten zijn voorzien van een BBU.

Ik houd de servers in sync met syncback se, dit programma start op als ik de backup server aan zet, hij gaat dan via ftp kijken of alles nog in sync is.
Op de main server heb ik hiervoor filezilla server draaien en de gebruiker heeft read only rechten op de mappen.

(12-5-2014)
Even een update de kasten hangen nu
[afbeelding]

Weer even een update

Ik heb beide servers voorzien van een 2 x 10 Gb netwerk kaart 2de hands via Ebay (Intel X520-T2 10Gb 10GbE Base-T Dual Port PCI-E) met 2x een Cat 7 kabel (teaming mode) er tussen en heb snelheden gezien rond de 400MB/sec

Ik had eerst de dual 1Gbit nic via een hp switch met trunking maar ik was daar niet tevreden over (schommelde tussen de 50Mb/sec en 175Mb/sec

Tevens heb ik de 4 x 4 TB Raid 5 verplaatst van de Main server naar de backup server en in de Main server zit nu 4x 5TB Raid 5, en aangezien beide kaarten areca zijn zag de andere areca kaart de raid set zonder problemen

Hierdoor komt mijn Storage op 66 TB ( netto 60 TB) voor de backup server en 59 TB ( netto 54 TB) voor mijn Main server

[DYX]

Nice! Heb zelf ook eens voor 10Gbit zitten kijken, maar dan moet de prijs voor de switch toch wel eerst naar beneden. tevens het stroomverbruik is aan de hoge kant.

Voor de rest wel grappig om te lezen over het geluidsniveau van de Norco. Heb zelf de fans ook vervangen door noctua PWM, maar kan niet zeggen dat hij erg stil is. Als ik de fans ook wat langzamer instel zie je de temperatuur ook erg hard omhoog gaan. Er zit dus wel een issue mbt de airflow in de Norco.

Ik zag me server zelf vorige gaan klagen over ruimte gebrek ( <1,5TB vrij), het komt alleen wat slecht uit nu. Dus dat zal nog even moeten wachten. Daarna wel denk 6x6TB erbij prikken

[SmiGueL]

thalantis schreef op dinsdag 16 februari 2016 @ 14:26:
Ik heb beide servers voorzien van een 2 x 10 Gb netwerk kaart 2de hands via Ebay (Intel X520-T2 10Gb 10GbE Base-T Dual Port PCI-E) met 2x een Cat 7 kabel (teaming mode) er tussen en heb snelheden gezien rond de 400MB/sec

Misschien is de oplossing uit de volgende video interessant voor de mensen in dit topic voor wie 2x 10 Gb/s kaartjes + switches nog 'iets' boven het budget zijn:

TLTW: 2x 4x1Gb/s kaartjes + simpele switch = 440MB/s @ $100.

[Q]

Linux kan dat ook met Bonding.

http://louwrentius.com/ac...-using-linux-bonding.html

[jacovn]

Freebsd zou het wellicht ook kunnen als ze smb 3 zouden implementeren..

[thalantis]

Ik heb geen 10Gb switch, ik de kaarten gewoon met 2 kabels aan elkaar gedaan en in teaming gezet

[FireDrunk]

FireDrunk in "Het grote ZFS topic"

[ Voor 92% gewijzigd door FireDrunk op 17-02-2016 09:07 ]

[Villean]

sdk1985 schreef op woensdag 27 januari 2016 @ 18:05:
Ik heb een gevreesde Seagate Archive HDD 8 TB aangeschaft. Op die manier is het wel erg makkelijk om in de 20+ TB te komen .

Valt op dat hij gewoon met 102 MB/s vult (gigabit). Gooi er momenteel batches van 500 GB op. Ik vermoed dat hij pas bij 33% vulling overschakelt op SMR. Over een paar honderd GB weet ik dat zeker.

Ik ben erg benieuwd naar je vindingen zit er sterk over te twijfelen om er 4 van deze in mn synology te stoppen.

[Q]

Oh ja, ik moet nog steeds eens gaan spelen met mijn eigen infiniband kaartjes )

[sdk1985]

Villean schreef op woensdag 17 februari 2016 @ 09:43:
[...]


Ik ben erg benieuwd naar je vindingen zit er sterk over te twijfelen om er 4 van deze in mn synology te stoppen.

Heb er een review van gemaakt: Seagate Archive HDD 8 TB Review.

TLDR: Ook na 50% vulling blijft de performance overeind. Hij outperformed normale schijven in access times en IOPS. Dankzij de caches liggen de 4K random writes op circa 10 MB/s bij een test bestand van 1 GB. Je kan de performance wel slopen door een clean te triggeren en dan snel volle load te eisen maar daar moest ik erg mijn best voor doen. Onder normaal NAS gebruik gaat dat niet voorkomen.

[Villean]

sdk1985 schreef op woensdag 17 februari 2016 @ 14:06:
[...]

Heb er een review van gemaakt: Seagate Archive HDD 8 TB Review.

TLDR: Ook na 50% vulling blijft de performance overeind. Hij outperformed normale schijven in access times en IOPS. Dankzij de caches liggen de 4K random writes op circa 10 MB/s bij een test bestand van 1 GB. Je kan de performance wel slopen door een clean te triggeren en dan snel volle load te eisen maar daar moest ik erg mijn best voor doen. Onder normaal NAS gebruik gaat dat niet voorkomen.

Tnx! Ik ga je review even door nemen.

Edit:
Wat ik wel lees in je review is dat het niet goed is voor RAID/ZFS maar dat je het wel oke is voor een NAS. Ik vind dat lastig te combineren want naar mijn idee heb je bijna altijd wel je disks in een NAS in RAID of iets dergelijks staan. Ik heb nu 4x 2TB in mijn synology staan en wil dat graag naar 4x 8TB brengen. Wordt er zelf niet helemaal duidelijk van of dit nu wel of niet slim is.

[ Voor 22% gewijzigd door Villean op 17-02-2016 15:24 ]

[Q]

sdk1985 schreef op woensdag 17 februari 2016 @ 14:06:
[...]

Heb er een review van gemaakt: Seagate Archive HDD 8 TB Review.

TLDR: Ook na 50% vulling blijft de performance overeind. Hij outperformed normale schijven in access times en IOPS. Dankzij de caches liggen de 4K random writes op circa 10 MB/s bij een test bestand van 1 GB. Je kan de performance wel slopen door een clean te triggeren en dan snel volle load te eisen maar daar moest ik erg mijn best voor doen. Onder normaal NAS gebruik gaat dat niet voorkomen.

Het spijt me zeer maar ik hoop dat mensen op basis van dat artikel geen verkeerde keuzes gaan maken. CiPHER en ik hebben al eerder aangegeven dat die tests met kleine bestanden niet relevant zijn.

Kijk uit met SMR schijven in RAID - aka: ik zou het sterk afraden.

[Lambo LP670 SV]

Q schreef op woensdag 17 februari 2016 @ 16:23:
[...]


Het spijt me zeer maar ik hoop dat mensen op basis van dat artikel geen verkeerde keuzes gaan maken. CiPHER en ik hebben al eerder aangegeven dat die tests met kleine bestanden niet relevant zijn.

Kijk uit met SMR schijven in RAID - aka: ik zou het sterk afraden.

Dat staat toch ook in zijn review? Valt prima te gebruiken en presteert eigenlijk erg goed maar gebruik hem niet voor RAID. Staat er letterlijk.

Ikzelf zit te kijken om een simpele file server te bouwen met 2 van deze schijvenr, puur voor wat media opslag.

[sdk1985]

Q schreef op woensdag 17 februari 2016 @ 16:23:
[...]


Het spijt me zeer maar ik hoop dat mensen op basis van dat artikel geen verkeerde keuzes gaan maken. CiPHER en ik hebben al eerder aangegeven dat die tests met kleine bestanden niet relevant zijn.

Kijk uit met SMR schijven in RAID - aka: ik zou het sterk afraden.

Als we over SSD's praten dan zijn de kleine files heilig en nu irrelevant? Het is gewoon een punt waarin de schijf opvallend in uit blinkt. Altijd mooi meegenomen, toch? Ik zou een dergelijk mechanisme ook graag in desktopschijven zien. Handig voor het updaten van games met veel kleine files (helaas past mijn game library nog altijd niet betaalbaar op een SSD).

Alle andere tests die ik kon verzinnen komen ook aan bod, waaronder de traces van Pcmark. Zoals Lambo LP670 SV terecht opmerkt staat er inderdaad in het artikel dat RAID gebruik wordt afgeraden.

Overigens is de toepassing van SMR nieuw maar alle onderdelen zijn op basis van eerdere schijven, aldus Seagate. Ten opzichte van een desktop schijf geven ze een jaar langer garantie. Vermoedelijk omdat hij gerate is op 24x7x180TB ipv de 8x5x50TB.

[aval0ne]

aval0ne schreef op maandag 09 mei 2011 @ 15:26:
En dit is mijn systeem:

HDD's: 13 x Samsung F3EG HD203WI 2TB + 1 extra als hotspare
RAID controller: Areca ARC-1280 (24x SATA300 RAID, XOR, 512MB, PCI-e x8)
RAID level: RAID 6, 1 array
Case: Antec Skeleton
HDD behuizing: 6x Cooler Master 4-in-3 Device Module, gewoon per 2 op mekaar gestapeld en verbonden met de areca controller in de Antec kast met 1m lange SATA kabels.
Voeding: Corsair AX750W 750W Modulair
Mobo: Gigabyte GA-EX58-UD3R
CPU: Intel Core i7 920
Mem: 3x Kingston ValueRAM KVR1333D3N9 2GB
Boot: OCZ Vertex 60GB
Download schijf: Intel X25M 80GB Postville

OS: Windows 7 x64

Bruto: 26TB
Netto: 22TB

Doel: verzamelen bewegend beeld en geluid. De server zal in een huis dat momenteel nog gebouwd wordt de XBMC HTPC van beeld voorzien en de bron vormen voor de muziekbibliotheek van het Sonos multi room audio systeem.

Achtergrond: ik ben gestart met 3 2TB schijven in RAID5 en ben dan beginnen expanden met telkens 1 schijf en vanaf 4 schijven draai ik RAID 6. Expandtijden niet meer echt werkbaar met dit aantal schijven (+60 uur), ik overweeg dan ook een 2de RAID array aan te maken.

Ben toevallig nog eens op dit draadje gestoten en het is leuk op nog een terug te lezen wat ik in 2011 gepost had . Wat misschien nog leuker is is dat deze setup vandaag de dag nog altijd 24/7 draait en sindsdien ongewijzigd is gebleven. Dus geen uitvallers of kapotte hard disks. Toch wel indrukwekkend van deze Samsung schijven zonder TLER.

[heuveltje]

(Wat) zijn de ervaringen met unraid hier eigenlijk ?
Nadat flexraid weer eens onduidelijke foutmeldingen geeft ben ik er wel klaar mee.
En unraid zIet er wel interessant uit.
Huiver alleen een beetje, dat ik alle data zou moeten omzetten.

[FREAKJAM]

heuveltje schreef op woensdag 30 maart 2016 @ 13:55:
(Wat) zijn de ervaringen met unraid hier eigenlijk ?
Nadat flexraid weer eens onduidelijke foutmeldingen geeft ben ik er wel klaar mee.
En unraid zIet er wel interessant uit.
Huiver alleen een beetje, dat ik alle data zou moeten omzetten.

Gebruik de term unraid in de zoekfunctie van dit topic en dan vind je al een aantal ervaringen.

[MvL]

Ik moet die meningen wel enigzinds nuanceren. Er is een hoop veranderd sinds de developer zich gedroeg als minder fijn persoon. Er zijn mensen aangenomen bij Limetech en volgens mij bestaat de groep nu uit 3 devs.

unRAID werkt erg goed met goedkope SMR drives omdat de paritiy op 1 schijf staat en niet zoals raid op meerdere schijven. In de huidige beta wordt zelfs 2 parity drives ondersteund.

Ook Docker is inmiddels toegevoegd aan unRAID. Dit werkt ook erg fijn.

Wat betreft de snelheid, gebruik gewoon een ssd als cache en schrijf je bestanden 's nachts naar de arry.

[heuveltje]

bedankt voor de reactie en nuancering.

Ik kwam voornamelijk reacties tegen van jacovn. en die leken nogal vertekend te zijn.
Ik heb ondertussen zelf al even lopen experimenteren met een trial key en wat losse 1tb schijven.
Op zich werkt het mooi.

Echter ik had even niet door, dat om dit te inplementeren ik een poort en disk vrij moet maken voor de parity. dat ik daarvoor 2 2tb schijven zou moeten vervangen door 2x4 TB . Samen met unraid pro key zou dat neerkomen op een E300 investering. Iets wat ik het nu nog niet waard vind.

En ik later wil overstappen op 8 TB Disken, dus dan moet ik er eigenlijk ook nu 1 kopen, die vervolgens half leeg blijft voor de komende tijd .

Dus omzet plannen, staan nu even op een laag pitje terwijl ik naar alternatieven zoek.

[ Voor 15% gewijzigd door heuveltje op 11-04-2016 14:31 ]

[Wyber]

Een update van mijn systeem wat ik in Nov 2012 al een heb gepost. http://gathering.tweakers...message/39346284#39346284

PS. op de foto's zijn 14 schijven te zien, foto's zijn genomen op het moment dat ik bezig was met het vervangen van 2 schijven.

Waarom "speciaal en interessant': 4 extra 3,5" Hdd posities gecreëerd, (in het extreemste geval zou de kast tot 18x 3,5" HDD + 2x 2,5" HDD kunnen huizen.)

Systeem wordt gebruikt voor: back-up (interne en externe) / media-server / Cloud back-up.




Tabel met systeem info

System specifications
Component	Value
Case	Fractal Design Node 804
CPU	Intel Pentium G3258
RAM	Corsair Vengeance LP CML8GX3M2A1600C9
Motherboard	MSI H87M-G43
Operating system	Ubuntu Snapraid
Controller	Supermicro AOC-USAS2-L8E 8-Port SAS/2
Hard drive	4x WD Red WD40EFRX, 4TB
Hard drive	2x Samsung EcoGreen F3, 2TB
Hard drive	7x WD Green WD20EARX/EADS, 2TB
Hard drive	OS drive: Seagate Momentus 5400.2 ST9120821AS
RAID array configuration	RAID 5: 2 pariteit 11 data
Netto storage capacity	26.6TB
Network	Standaard gigabit
UPS	Nee
Filesystem
Idle power usage	geen idee, heb geen meter tot mijn beschikking
Extra

[sdk1985]

Even een ervaringen update mbt de Seagate Archive HDD. De eerste +- 3 TB heb ik niets kunnen merken van de nadelen van de SMR techniek. Echter nu er nog slechts 2 TB vrij is ga je bij grote transfers tegen de beperkingen van de schijf aanlopen.

Zo probeer ik nu 400 GB over te zetten en nadat de cache vol zat is de snelheid instabiel geworden, van 4MB/s tot 70 MB/s. Het gaat nu nog meer dan 2 uur en 15 minuten duren. De eerste 3 TB was dat haast niet voor elkaar te krijgen.

Zoals ik hem normaal gebruik merk ik daar eigenlijk niets van (dan komt het of traag binnen via het netwerk of het blijft onder de 20 GB). Sterker nog door de writecache is hij zelf sneller dan een normale schijf. Echter indien haast is geboden is het dus niet handig.

Zelf zit ik nu op 18 en komt er waarschijnlijk deze week nog een archive HDD 8 TB bij. Ik ga me echter eerst eens inlezen of het meteen kan combineren met ReFS of unraid of iets vergelijkbaars. Heb namelijk ook nog een losse 120 GB SSD liggen dus unraid zou dan wel leuk zijn.

Echter unraid doet niets tegen bitrot? Want als je dan een oude gare schijf erin hebt zitten dan gaat die gare data vrolijk mee naar je parity neem ik aan. Tot het moment dat de schijf echt defect is (niet meer spinned, gaat kraken, enz). Echter dan kan je al te laat zijn, of begrijp ik het verkeerd?

[ Voor 32% gewijzigd door sdk1985 op 28-06-2016 23:13 ]

[Q]

Harde schijven sterven meestal of ze genereren bad sectors, maar dat is geen silent data corruptie. Echte silent data corruptie is zeldzaam. De meeste mensen die geen RAID oid toepassen lopen met name het risico dat een paar individuele files corrupt raken of dat ze gewoon alle data op een schijf verliezen.

Ik denk dat je nu eigenlijk zelf precies meemaakt waar CiPHER en ik in het verleden ook mensen wel voor hebben gewaarschuwd. Het hoort bij SMR dus voor jou is het gewoon acccepteren dat 'even snel' iets doen geen optie is want dat kunnen de schijven niet aan. Maar als geduld een optie is dan zou het wel goed moeten gaan.

[Mevius]

sdk1985 schreef op dinsdag 28 juni 2016 @ 22:59:
Zelf zit ik nu op 18 en komt er waarschijnlijk deze week nog een archive HDD 8 TB bij. Ik ga me echter eerst eens inlezen of het meteen kan combineren met ReFS of unraid of iets vergelijkbaars. Heb namelijk ook nog een losse 120 GB SSD liggen dus unraid zou dan wel leuk zijn.

Echter unraid doet niets tegen bitrot? Want als je dan een oude gare schijf erin hebt zitten dan gaat die gare data vrolijk mee naar je parity neem ik aan. Tot het moment dat de schijf echt defect is (niet meer spinned, gaat kraken, enz). Echter dan kan je al te laat zijn, of begrijp ik het verkeerd?

Zelf draai ik SnapRAID.

pros:
- Power saving
- Less drive usage, so in theory more longevity for all drives
- All drives are individual and therefore getting URE during rebuilding array only affects one drive
- Drives can be added to the array afterwards and drives can be full
- Very low CPU usage and not memory dependent like ZFS

cons:
- How to manage your data so that not just one drives has let say 70% of the most seeded data and thus spinning all the time while the rest on sleep mode most of the time. This ultimately leads one drive failing way before the others?
- RAID speed compared to ZFS. Basically only one drive max speed, as ZFS has the speed of all drives combined.
- Not so mature and support can be limited
- If missed RAID snapshot, data lost till the last snapshot taken(power surge could cause one of these incidents or computer crash)

[sdk1985]

Q schreef op woensdag 29 juni 2016 @ 13:39:
Harde schijven sterven meestal of ze genereren bad sectors, maar dat is geen silent data corruptie. Echte silent data corruptie is zeldzaam. De meeste mensen die geen RAID oid toepassen lopen met name het risico dat een paar individuele files corrupt raken of dat ze gewoon alle data op een schijf verliezen.

Ik denk dat je nu eigenlijk zelf precies meemaakt waar CiPHER en ik in het verleden ook mensen wel voor hebben gewaarschuwd. Het hoort bij SMR dus voor jou is het gewoon acccepteren dat 'even snel' iets doen geen optie is want dat kunnen de schijven niet aan. Maar als geduld een optie is dan zou het wel goed moeten gaan.

Het lijkt er overigens dus wel op dat de eerste 3 TB van de SMR techniek gewoon "normaal" wordt weggeschreven. Ik heb hem namelijk tot over de 3 TB kunnen vullen met 100-150 MB/s. Pas nu merk ik het op.

Ik gebruik de Archive HDD als cold-storage (films etc), alleen gisteren had ik dus een SMART error op een losse disk en wilde ik de data veiligstellen. Dat heb ik na 5 minuten geannuleerd en ben de belangrijkste data naar een SSD gaan pompen want met gemiddeld 40 MB/s duurt het mij veel te lang.

Mbt de data corruptie: heb het in de firmware release notes van een Samsung schijf voorbij zien komen dat de write buffer data corruptie veroorzaakt. Dus wat dat betreft ben ik er hierdoor een beetje bang voor dat één schijf een hele array gaat lopen corrupten. Volgens mij had Seagate 7200.11 ook een keer zo'n fout erin.

edit:

If the host issues an identify command during an action of writing data in NCQ, the data's writing can be destabilized, and can lead to data loss

Dus mijn grootste angst tegen één grote array is eigenlijk dat zoiets alles opblaast. Maar daar hebben jullie tot heden geen last van?

Mevius schreef op woensdag 29 juni 2016 @ 14:14:
[...]

Zelf draai ik SnapRAID.

pros:
- Power saving
- Less drive usage, so in theory more longevity for all drives
- All drives are individual and therefore getting URE during rebuilding array only affects one drive
- Drives can be added to the array afterwards and drives can be full
- Very low CPU usage and not memory dependent like ZFS

cons:
- How to manage your data so that not just one drives has let say 70% of the most seeded data and thus spinning all the time while the rest on sleep mode most of the time. This ultimately leads one drive failing way before the others?
- RAID speed compared to ZFS. Basically only one drive max speed, as ZFS has the speed of all drives combined.
- Not so mature and support can be limited
- If missed RAID snapshot, data lost till the last snapshot taken(power surge could cause one of these incidents or computer crash)

[afbeelding]

Bedankt ik ga me eens inlezen en dan een apart topic aanmaken.

[ Voor 36% gewijzigd door sdk1985 op 29-06-2016 15:34 ]

[HyperBart]

Wyber schreef op maandag 11 april 2016 @ 15:07:
Een update van mijn systeem wat ik in Nov 2012 al een heb gepost. http://gathering.tweakers...message/39346284#39346284

PS. op de foto's zijn 14 schijven te zien, foto's zijn genomen op het moment dat ik bezig was met het vervangen van 2 schijven.

Waarom "speciaal en interessant': 4 extra 3,5" Hdd posities gecreëerd, (in het extreemste geval zou de kast tot 18x 3,5" HDD + 2x 2,5" HDD kunnen huizen.)

Systeem wordt gebruikt voor: back-up (interne en externe) / media-server / Cloud back-up.

[afbeelding]
[afbeelding]

Tabel met systeem info

System specifications
Component	Value
Case	Fractal Design Node 804
CPU	Intel Pentium G3258
RAM	Corsair Vengeance LP CML8GX3M2A1600C9
Motherboard	MSI H87M-G43
Operating system	Ubuntu Snapraid
Controller	Supermicro AOC-USAS2-L8E 8-Port SAS/2
Hard drive	4x WD Red WD40EFRX, 4TB
Hard drive	2x Samsung EcoGreen F3, 2TB
Hard drive	7x WD Green WD20EARX/EADS, 2TB
Hard drive	OS drive: Seagate Momentus 5400.2 ST9120821AS
RAID array configuration	RAID 5: 2 pariteit 11 data
Netto storage capacity	26.6TB
Network	Standaard gigabit
UPS	Nee
Filesystem
Idle power usage	geen idee, heb geen meter tot mijn beschikking
Extra

Hoe heb je die extra HDD's gemonteerd?

Ik heb ook een tijdje naar die kast zitten kijken maar om één of andere reden ben ik er toen niet voor gegaan. Ben me nu aan het afvragen waarom, want dit ding kan standaard ook 10 disks herbergen en 2 SSD's. Dat had voldoende moeten zijn indertijd , nou ja.

[Wyber]

HyperBart schreef op woensdag 29 juni 2016 @ 15:41:
[...]



Hoe heb je die extra HDD's gemonteerd?

Bovenste HDD hangt met twee 5,25 to 3,5 adapters (extra gaatjes geboord in de adapters) aan de bevestigingsgaten die voor de top fan zijn bedoeld.

Daarna heb ik de andere 3 er onder gehangen met een paar stukjes metaal die ik nog had liggen van een oude monitor. dit was het eerste staal/blik wat ik in de schuur tegen kwam.

[HyperBart]

Wyber schreef op woensdag 29 juni 2016 @ 15:57:
[...]


Bovenste HDD hangt met twee 5,25 to 3,5 adapters (extra gaatjes geboord in de adapters) aan de bevestigingsgaten die voor de top fan zijn bedoeld.

Daarna heb ik de andere 3 er onder gehangen met een paar stukjes metaal die ik nog had liggen van een oude monitor. dit was het eerste staal/blik wat ik in de schuur tegen kwam.

Interessant, mag je altijd wat meer foto's van maken.

[The Lord]

sdk1985 schreef op woensdag 29 juni 2016 @ 15:26:
Het lijkt er overigens dus wel op dat de eerste 3 TB van de SMR techniek gewoon "normaal" wordt weggeschreven. Ik heb hem namelijk tot over de 3 TB kunnen vullen met 100-150 MB/s. Pas nu merk ik het op.

Dat komt door de overlappende 'shingles' van naast elkaar liggende sporen. In eerste instantie gaat de HDD alle niet overlappende sporen beschrijven, totdat dit niet meer kan. Als dan de overlappende moeten worden beschreven wordt het schrijf proces veel intensiever met meer IO's op de HDD dan het FS vraagt.

Ik gebruik de Archive HDD als cold-storage (films etc), alleen gisteren had ik dus een SMART error op een losse disk en wilde ik de data veiligstellen. Dat heb ik na 5 minuten geannuleerd en ben de belangrijkste data naar een SSD gaan pompen want met gemiddeld 40 MB/s duurt het mij veel te lang.

Btw. Een move van data kan langzamer zijn dan een copy vanaf een SMR schijf.

[sdk1985]

Copy vanaf heb ik inderdaad niet gemerkt dat het een SMR schijf is. Dit was echt een ongeplande copy naar de SMR schijf die al redelijk vol zit. Normaal is het meestal 2-10GB per file met enkele files per dag.

Hoeveel wordt er bij snapraid eigenlijk dagelijks naar zo'n parity disk geschreven? De eerste +- 3 TB zal het überhaupt geen probleem opleveren. Maar het punt dat er reeds 4 TB is bezet en er wordt meer dan 100GB geschreven dan wordt het een ander verhaal.

[azerty]

Alvast een teaser plaatsen



Dat is het overgrote deel van deze wenslijst:

#	Product	Prijs	Subtotaal
1	Intel Core i3-6100 Tray	€ 111,50	€ 111,50
1	ASRock Rack E3C236D4U	€ 257,25	€ 257,25
20	WD Blue WD40EZRZ, 4TB	€ 133,95	€ 2.679,-
1	Logic Case 4U Server Case 20 external 3.5" Hot-Swap bays 650mm deep	€ 0,-	€ 0,-
1	Delock Cable mini SAS 36pin > 4x SATA metal (SFF 8087 > 4x SATA) 50cm	€ 16,65	€ 16,65
4	Supermicro SFF8087 to SFF8087 (CBL-0281L)	€ 9,44	€ 37,76
2	Scythe Mini Kaze , 40mm	€ 5,-	€ 10,-
1	Crucial CT2K16G4RFD4213	€ 168,43	€ 168,43
3	Dell PERC H200	€ 150,50	€ 451,50
1	Corsair RM550x	€ 93,95	€ 93,95
Bekijk collectie Importeer producten		Totaal	€ 3.826,04

Ontbreekt op de foto: de scythe 40mm fans & 10 disks (besteld, maar nog niet verzonden)

[Mezz0]

Kom je dan wel boven de 20TB? :):):):):)

[IceTeaGX]

Waarom die 2 * 40mm ventilatoren?
Enig potentieel doel zijn de PERCs volgens mij, maar dat zijn er 3...

[Q]

Leuk, wat ga je er op draaien?

[ArcticTiger]

azerty schreef op dinsdag 12 juli 2016 @ 11:51:
Alvast een teaser plaatsen

Mooie setup

Maarreh...
Kan je die 3e PERC kaarten wel kwijt op dat moederbord?
Want die heeft 1x PCIe 3.0 x1, 1x PCIe 3.0 x8 en 1x PCIe 3.0 x4
Die PERC kaarten zijn PCIe 2.0 x8?
Of neem je genoegen met de mindere doorvoer van PCIe x4?

[azerty]

ArcticTiger schreef op dinsdag 12 juli 2016 @ 15:06:
[...]


Mooie setup

Maarreh...
Kan je die 3e PERC kaarten wel kwijt op dat moederbord?
Want die heeft 1x PCIe 3.0 x1, 1x PCIe 3.0 x8 en 1x PCIe 3.0 x4
Die PERC kaarten zijn PCIe 2.0 x8?
Of neem je genoegen met de mindere doorvoer van PCIe x4?

Ik heb 1 kaart reserve, als er iets misgaat bij het flashen.

Dan moet ik er 2 kwijt, en volgens de specs:

PCIe 3.0 x 16 - 1 slot(PCIE4/6: x16/x8, x8/x8 )
PCIe 3.0 x 8 - 1 slot(PCIE4/6 x0/x8 )

http://www.asrockrack.com...=E3C236D4U#Specifications

Zou dus perfect moeten kloppen

Mezz0 schreef op dinsdag 12 juli 2016 @ 14:24:
Kom je dan wel boven de 20TB? :):):):):)

Hopelijk

IceTeaGX schreef op dinsdag 12 juli 2016 @ 14:44:
Waarom die 2 * 40mm ventilatoren?
Enig potentieel doel zijn de PERCs volgens mij, maar dat zijn er 3...

PERC's inderdaad, en maar 2 omdat ik 1 PERC reserve heb voor het geval het flashen misloopt

Q schreef op dinsdag 12 juli 2016 @ 14:53:
Leuk, wat ga je er op draaien?

ZFS, maar ik ben er nog niet 100% uit of het ZOL of terug ZFSGuru gaat worden.

[ Voor 33% gewijzigd door azerty op 12-07-2016 16:49 ]

[Q]

azerty schreef op dinsdag 12 juli 2016 @ 16:46:

ZFS, maar ik ben er nog niet 100% uit of het ZOL of terug ZFSGuru gaat worden.

Ok, heb zelf wel de indruk dat ZFSGuru dood is als project maar als het draait dan draait het.

[azerty]

Q schreef op dinsdag 12 juli 2016 @ 18:10:
[...]


Ok, heb zelf wel de indruk dat ZFSGuru dood is als project maar als het draait dan draait het.

Mijn vorige server die nu ergens halverwege de lijst staat draait dus op ZFSGuru, maar inderdaad, juist omdat er niet te veel meer lijkt te gebeuren én ik nog wat andere zaken wil uitproberen die ik met mijn Linux kennis wel voor elkaar zou moeten krijgen (tov BSD anders) denk ik er dus over om maar ZoL te nemen in plaats.

[BartNL]

het lijkt alsof je de Delock Cable mini SAS 36pin > 4x SATA omgekeerd wilt gebruiken dus van 4x sata op moederbord naar SAS backplane. Zou even checken of dat met deze kabel wel werkt?

[azerty]

BartNL schreef op dinsdag 12 juli 2016 @ 19:44:
het lijkt alsof je de Delock Cable mini SAS 36pin > 4x SATA omgekeerd wilt gebruiken dus van 4x sata op moederbord naar SAS backplane. Zou even checken of dat met deze kabel wel werkt?

Ik ga dat wel merken zodra ik de disks aansluit

Eerst uitvissen wat er mis is aan het geheugen

[rikadoo]

azerty schreef op dinsdag 12 juli 2016 @ 20:17:
[...]


Ik ga dat wel merken zodra ik de disks aansluit

Eerst uitvissen wat er mis is aan het geheugen

Als je van mobo naar SAS backplane wilt heb je een Reverse sas kabel nodig, die je nu hebt is Forward en is voor SAS-controller naar 4x sata HDD bedoeld.

[BartNL]

azerty schreef op dinsdag 12 juli 2016 @ 20:17:
[...]


Ik ga dat wel merken zodra ik de disks aansluit

Eerst uitvissen wat er mis is aan het geheugen

waarschijnlijk ondersteund je mobo geen registered ram?

[azerty]

BartNL schreef op dinsdag 12 juli 2016 @ 22:50:
[...]

waarschijnlijk ondersteund je mobo geen registered ram?

Ik haal morgen eerst een ander setje ram om hem in het bios te krijgen (en uit te sluiten dat het aan iets anders ligt), dan upgrade ik het bios & probeer opnieuw, want (huidige bios is 1.4):

1.5:
1.Improve ECC memory compatibility
...

Redelijke kans dat dat het probleem oplost

Zo niet, dan stuur ik het ram wel terug naar Amazon, en zoek ik iets anders...

rikadoo schreef op dinsdag 12 juli 2016 @ 22:22:
[...]


Als je van mobo naar SAS backplane wilt heb je een Reverse sas kabel nodig, die je nu hebt is Forward en is voor SAS-controller naar 4x sata HDD bedoeld.

Wist ik niet... Ik ging ervan uit dat de data beide richtingen opkon, net zoals gewone sata aansluitingen. Dan maar eens kijken of ik die reverse breakout ergens op de kop kan tikken.

[BartNL]

azerty schreef op dinsdag 12 juli 2016 @ 22:57:
[...]
Redelijke kans dat dat het probleem oplost

registered RAM gaat niet ineens werken door een bios upgrade je moederbord moet het expliciet ondersteunen. Volgens mij is dat bij jouw moederbord niet het geval.

[azerty]

BartNL schreef op dinsdag 12 juli 2016 @ 23:49:
[...]

registered RAM gaat niet ineens werken door een bios upgrade je moederbord moet het expliciet ondersteunen. Volgens mij is dat bij jouw moederbord niet het geval.

In dat geval weet ik tenminste dat het moederbord niet is

Het setje wat ik ga halen is gelukkig niet zo duur, en ik kan het gebruiken in het volgende project wat op de planning staat anders

Update: uiteraard accepteerd het mobo dus geen R(egistered) DIMM... Retourneren dus maar

[ Voor 8% gewijzigd door azerty op 13-07-2016 11:35 ]

[sdk1985]

Even nog een praktische snapraid vraag tussendoor...

Als je een 1 TB disk aan je pool met 8 TB parity toegevoegd (Wordt iets van 8,8,8,3,3,1,1,1) gaat die 8 TB schijf dan voor 7 TB hashes van 0 maken of is de extra belasting beperkt tot die ene TB? In het eerste geval kan ik wellicht beter twee aparte pools maken... Een pool van 8 TB schijven en een pool van 3 TB en lager ivm de dagelijkse write belasting. Kost natuurlijk wel een extra 3 TB schijf en een sata poort. Idealiter is snapraid zo slim dat hij hooguit 1 keer lang bezig is en daarna alleen de changes update (die zijn dagelijks nihil).

[ Voor 20% gewijzigd door sdk1985 op 17-07-2016 23:20 ]

[Aramiss]

Wyber schreef op maandag 11 april 2016 @ 15:07:
Een update van mijn systeem wat ik in Nov 2012 al een heb gepost. http://gathering.tweakers...message/39346284#39346284

PS. op de foto's zijn 14 schijven te zien, foto's zijn genomen op het moment dat ik bezig was met het vervangen van 2 schijven.

Waarom "speciaal en interessant': 4 extra 3,5" Hdd posities gecreëerd, (in het extreemste geval zou de kast tot 18x 3,5" HDD + 2x 2,5" HDD kunnen huizen.)

Systeem wordt gebruikt voor: back-up (interne en externe) / media-server / Cloud back-up.

[afbeelding]
[afbeelding]

Tabel met systeem info

System specifications
Component	Value
Case	Fractal Design Node 804
CPU	Intel Pentium G3258
RAM	Corsair Vengeance LP CML8GX3M2A1600C9
Motherboard	MSI H87M-G43
Operating system	Ubuntu Snapraid
Controller	Supermicro AOC-USAS2-L8E 8-Port SAS/2
Hard drive	4x WD Red WD40EFRX, 4TB
Hard drive	2x Samsung EcoGreen F3, 2TB
Hard drive	7x WD Green WD20EARX/EADS, 2TB
Hard drive	OS drive: Seagate Momentus 5400.2 ST9120821AS
RAID array configuration	RAID 5: 2 pariteit 11 data
Netto storage capacity	26.6TB
Network	Standaard gigabit
UPS	Nee
Filesystem
Idle power usage	geen idee, heb geen meter tot mijn beschikking
Extra

Wat heb je aangepast of getweakt zodat er meer schijven in kunnen?
Want ik kan het op de foto's niet direct zien (ben niet bekend met de NODE).

[Wyber]

Dan heb ik het nog redelijk netjes gedaan, het gaat om de 4 schijven die voor het moederbord hangen.

[azerty]

Met mijn systeem wat de kopieerfase benaderd, zijn er nog suggesties voor benchmarks?

Ik heb al de volgende benchmarks uitgevoerd:

bonnie++

code:

bonnie++ -u root -d /tank/public/ -s 64396MM -n 10:102400:1024:1024

+---------------+---------------------------------------------------------------------+
+ Version  1.97 +  ------Sequential Output------  + --Sequential Input- + --Random-   +
+ Concurrency 1 +  -Per Chr- --Block-- -Rewrite-  + -Per Chr- --Block-- + --Seeks--   +
+ Machine       + Size K/sec %CP K/sec %CP K/sec  + %CP K/sec %CP K/sec %CP sec   %CP +
+ zfs           + 64396M 234  99 590721 50 388118 + 44   721  96 902209  40 237.4 6   +
+ Latency       +    46078us     136ms     197ms  +   106ms     126ms     170ms       +
+ Version  1.97 + ------Sequential Create------   + --------Random Create--------     +
+ zfs           + -Create-- --Read--- -Delete--   + -Create-- --Read--- -Delete--     +
+ files:max:min + /sec %CP  /sec %CP  /sec %CP    + /sec %CP  /sec %CP  /sec %CP      +
+ 10:102400:1024/1024  6298  75 +++++ +++ +++++ +++  6365  76 +++++ +++ +++++ +++
+ Latency       +  8034us      99us     632us     + 19245us     236us    5287us       +
+---------------+---------------------------------------------------------------------+

dd

code:

root@zfs:/tank/public# dd if=/dev/zero of=/tank/public/test.bin bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 18.9127 s, 1.1 GB/s

root@zfs:/tank/public# dd if=/tank/public/test.bin of=/dev/zero bs=16M
1250+0 records in
1250+0 records out
20971520000 bytes (21 GB) copied, 20.1948 s, 1.0 GB/s

Ik ben tevreden denk ik

[FireDrunk]

Compressie aangezet? Met zo'n system kan dat nooit kwaad.

[HyperBart]

azerty schreef op zondag 24 juli 2016 @ 22:11:
Met mijn systeem wat de kopieerfase benaderd, zijn er nog suggesties voor benchmarks?

Ik heb al de volgende benchmarks uitgevoerd:

bonnie++

code:

bonnie++ -u root -d /tank/public/ -s 64396MM -n 10:102400:1024:1024

+---------------+---------------------------------------------------------------------+
+ Version  1.97 +  ------Sequential Output------  + --Sequential Input- + --Random-   +
+ Concurrency 1 +  -Per Chr- --Block-- -Rewrite-  + -Per Chr- --Block-- + --Seeks--   +
+ Machine       + Size K/sec %CP K/sec %CP K/sec  + %CP K/sec %CP K/sec %CP sec   %CP +
+ zfs           + 64396M 234  99 590721 50 388118 + 44   721  96 902209  40 237.4 6   +
+ Latency       +    46078us     136ms     197ms  +   106ms     126ms     170ms       +
+ Version  1.97 + ------Sequential Create------   + --------Random Create--------     +
+ zfs           + -Create-- --Read--- -Delete--   + -Create-- --Read--- -Delete--     +
+ files:max:min + /sec %CP  /sec %CP  /sec %CP    + /sec %CP  /sec %CP  /sec %CP      +
+ 10:102400:1024/1024  6298  75 +++++ +++ +++++ +++  6365  76 +++++ +++ +++++ +++
+ Latency       +  8034us      99us     632us     + 19245us     236us    5287us       +
+---------------+---------------------------------------------------------------------+

dd

code:

root@zfs:/tank/public# dd if=/dev/zero of=/tank/public/test.bin bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 18.9127 s, 1.1 GB/s

root@zfs:/tank/public# dd if=/tank/public/test.bin of=/dev/zero bs=16M
1250+0 records in
1250+0 records out
20971520000 bytes (21 GB) copied, 20.1948 s, 1.0 GB/s

Ik ben tevreden denk ik

Das vergelijkbaar met wat ik met 20 x Hitachi 4TB haalde en half gevuld.

[azerty]

FireDrunk schreef op maandag 25 juli 2016 @ 09:27:
Compressie aangezet? Met zo'n system kan dat nooit kwaad.

Geen compressie, maar ik vraag me af in hoeverre media (het grootste deel van de collectie) comprimeerbaar is

HyperBart schreef op maandag 25 juli 2016 @ 11:39:
[...]


Das vergelijkbaar met wat ik met 20 x Hitachi 4TB haalde en half gevuld.

Ik ga zeker dan nog een benchmark doen als mijn huidige data overgezet is, eens zien wat er van overblijft als hij half gevuld is ook.

[FireDrunk]

Compressie helpt ook in je disk space losses die komen door een niet optimale RAIDZ array.
Ik kon even niet zo snel terugvinden wat voor Pool je met je 20 disks gemaakt had. Als het 2*10disks in RAIDZ2 is, heb je nergens last van. Iets anders gaat je waarschijnlijk een paar % disk space kosten. Dan helpt compressie weer om dit te minimaliseren.

[GeeMoney]

azerty schreef op zondag 24 juli 2016 @ 22:11:
Met mijn systeem wat de kopieerfase benaderd, zijn er nog suggesties voor benchmarks?

Ik heb al de volgende benchmarks uitgevoerd:

bonnie++

code:

bonnie++ -u root -d /tank/public/ -s 64396MM -n 10:102400:1024:1024

+---------------+---------------------------------------------------------------------+
+ Version  1.97 +  ------Sequential Output------  + --Sequential Input- + --Random-   +
+ Concurrency 1 +  -Per Chr- --Block-- -Rewrite-  + -Per Chr- --Block-- + --Seeks--   +
+ Machine       + Size K/sec %CP K/sec %CP K/sec  + %CP K/sec %CP K/sec %CP sec   %CP +
+ zfs           + 64396M 234  99 590721 50 388118 + 44   721  96 902209  40 237.4 6   +
+ Latency       +    46078us     136ms     197ms  +   106ms     126ms     170ms       +
+ Version  1.97 + ------Sequential Create------   + --------Random Create--------     +
+ zfs           + -Create-- --Read--- -Delete--   + -Create-- --Read--- -Delete--     +
+ files:max:min + /sec %CP  /sec %CP  /sec %CP    + /sec %CP  /sec %CP  /sec %CP      +
+ 10:102400:1024/1024  6298  75 +++++ +++ +++++ +++  6365  76 +++++ +++ +++++ +++
+ Latency       +  8034us      99us     632us     + 19245us     236us    5287us       +
+---------------+---------------------------------------------------------------------+

dd

code:

root@zfs:/tank/public# dd if=/dev/zero of=/tank/public/test.bin bs=1M count=20000
20000+0 records in
20000+0 records out
20971520000 bytes (21 GB) copied, 18.9127 s, 1.1 GB/s

root@zfs:/tank/public# dd if=/tank/public/test.bin of=/dev/zero bs=16M
1250+0 records in
1250+0 records out
20971520000 bytes (21 GB) copied, 20.1948 s, 1.0 GB/s

Ik ben tevreden denk ik

/dev/zero "dd-en" is natuurlijk een eitje. Probeer /dev/urandom maar eens
Kan je geen iorate gebruiken?

Ik gebruik in mijn werk iorate om mid/high-end storage boxen te testen vanaf hosts, heeft wel even een leercurve en je moet goed weten wat je wilt en wat de verwachtingen mogen/kunnen zijn. (blocksize, random/sequential,cached/un-cached etc.)
Met iorate kan je in ieder geval bottlenecks goed opzoeken. (zowel aan de host als storage kant )

[ Voor 8% gewijzigd door GeeMoney op 25-07-2016 13:29 ]

[azerty]

FireDrunk schreef op maandag 25 juli 2016 @ 12:39:
Compressie helpt ook in je disk space losses die komen door een niet optimale RAIDZ array.
Ik kon even niet zo snel terugvinden wat voor Pool je met je 20 disks gemaakt had. Als het 2*10disks in RAIDZ2 is, heb je nergens last van. Iets anders gaat je waarschijnlijk een paar % disk space kosten. Dan helpt compressie weer om dit te minimaliseren.

2 VDEVS van 10 disks in RAIDZ2 inderdaad, zou optimaal moeten zijn

GeeMoney schreef op maandag 25 juli 2016 @ 13:26:
[...]


/dev/zero "dd-en" is natuurlijk een eitje. Probeer /dev/urandom maar eens
Kan je geen iorate gebruiken?

Ik gebruik in mijn werk iorate om mid/high-end storage boxen te testen vanaf hosts, heeft wel even een leercurve en je moet goed weten wat je wilt en wat de verwachtingen mogen/kunnen zijn. (blocksize, random/sequential,cached/un-cached etc.)
Met iorate kan je in ieder geval bottlenecks goed opzoeken. (zowel aan de host als storage kant )

/dev/zero was omdat er al een paar oudere benchmarks hier in het topic stonden daarmee, en op een ander forum ook. IORate kan ik wel nog eens naar kijken though.

[FireDrunk]

@GeeMonkey, kan iorate "zien" op welke layer de IOPS verstookt worden dan?
Want in het geval van ZFS moet je rekening houden met je ARC hit ratio, (eventueel je L2ARC hit ratio), je vdev cache ratio, en daarvoor zit misschien zelfs nog client caching (in het geval van iSCSI).

Ik heb wel eens zitten kijken naar of er tools zijn die dit goed uit plotten (verschil tussen frontend iops en backend iops), maar die zijn er maar weinig.