2 harde schijven in raid 0 niet echt supper snel

[Verwijderd]

Hallo,

Ik heb nu al een tijdje een nieuwe pc.
Hier ben ik zeer tevreden over.
De games draaien allemaal goed, en op max
Echter vind ik de laadtijd wel erg langzaam.
Als ik nu bij mijn windows score kijk zie ik dat mijn harde schijf een magere 5.9 scoort.
En dat terwijl ik 2 schijven in raid0 heb staan.
Mijn moederboard is een M4A87TD EVO.
En de hardeschijven zijn, WD Caviar Green WD5000AADS

Nu vraag ik me af, heb ik iets fout ingesteld?
Of is dit echt de snelheid die ik kan halen?

In dat geval zal ik overwegen om deze 2 als opslag te gebuiken en er een vertex3 in te proppen.

Groeten,
Bas


EDIT,
Nog even een linkje,
http://www.alternate.nl/h...8/?tab=3&page=1#tabberBox

[ Voor 11% gewijzigd door Verwijderd op 16-11-2011 20:43 ]

[Swordlord]

Windows score is geen benchmark... dat is absoluut een score die je niet moet volgen, want het is niet te volgen...

Vertel eens wat meer over je raid?
Stripe size? etc etc
Heb je een serieuze benchmark al eens gedraaid? (Crystal disk mark)


Edit... Een vertex 3 wil je niet in de PC proppen... zijn niet echt betrouwbaar...

[ Voor 24% gewijzigd door Swordlord op 16-11-2011 20:50 ]

[Verwijderd]

Heb ook 5.9 met dezelfde hdd`s in raid-0, maar wpi is kut, kijk gewoon naar een echte benchmark!
Haal zelf 175mbyte/s read/write, windows boot+login in 56sec, fedora 16 boot+login in 40sec
Bij welke games haal je een langzame laadtijd?

[ Voor 29% gewijzigd door Verwijderd op 16-11-2011 20:48 ]

[PilatuS]

WD Caviar Green schijven zijn ook bedoelt als stille, koele en zuinige opslag. Echt snel zijn ze niet.

[rm_a_rayman]

WD Caviar Green WD5000AADS

zegt eigenlijk al voldoende.
Green versies zijn de langzaamste schijven (lagere rpm) en meer bedoeld voor opslag.

Voor snelle laadtijden is een ssd zeker een must.

[Ventieldopje]

Als ik me niet vergis draaien de Green series op 5400 rpm ipv 7200

[TERW_DAN]

Ik heb tijden met een set WD Greens in RAID gedraaid. Tuurlijk ze zijn iets trager dan 7200RPMs, maar alsnog kun je er wel de nodige performance mee halen hoor.

[rookie no. 1]

WD Green-series draaien op 5900rpm en zelfs WD zelf geeft aan dat je deze series NIET in een RAID-setup moet draaien. Waarschijnlijk omdat ze erg vaak down/up spinnen, waardoor je RAID-set stuk kan gaan.

Wil je echt performance? Koop een SSD, de goedkoopste (momenteel OCZ Vertex PLUS) zal je al verbaast doen staan!

[redfoxert]

De WPI is sowieso gelimiteerd op 5.9 voor conventionele harddisks. Wil je sneller moet je sowieso al een SSD gaan nemen. En zoals gezegd, een echte benchmark zegt veel meer.

[Verwijderd]

Ow,
Ik dacht dat ze gewoon 7200 rpm waren.
Het is misschien dan inderdaad ook slimmer om ze niet in raid te zetten.
Of kijken of ik de energie zuinige functie uit kan zetten.

Het grote nadeel van ssd is de capaciteit.
Ik weet nu al dat ik straks niet anders bezig ben dan het verwijderen en installeren van games.
Op dit moment heb ik er 31 geïnstalleerd en dan nog niet eens de steam games.
En mijn schijf is nu voor 455GB vol.
Ik denk dat ik er toch nog eventjes mee wacht.

De snelheden die Crystal disk mark me geeft zijn;

	Read	Write
seq	144.5	132.4
512K	26.51	57.28
4K	0.248	1.234
4K QD32	0.637	1.085

Nu staat er niets belangrijks op mijn pc.
Alles wat echt waarde of tijd heeft gekost staat ook geback-upt.
Ik denk dat ik de situatie zo hou tot ssd echt wat aantrekkelijker voor mij wordt.
Wat waarschijnlijk nog wel eventjes gaat duren, zeker nu Taiwan natte voeten heeft.

[ Voor 13% gewijzigd door Verwijderd op 16-11-2011 21:47 ]

[PilatuS]

Verwijderd schreef op woensdag 16 november 2011 @ 21:42:
Ow,
Ik dacht dat ze gewoon 7200 rpm waren.
Het is misschien dan inderdaad ook slimmer om ze niet in raid te zetten.
Of kijken of ik de energie zuinige functie uit kan zetten.

Het grote nadeel van ssd is de capaciteit.
Ik weet nu al dat ik straks niet anders bezig ben dan het verwijderen en installeren van games.
Op dit moment heb ik er 31 geïnstalleerd en dan nog niet eens de steam games.
En mijn schijf is nu voor 455GB vol.
Ik denk dat ik er toch nog eventjes mee wacht.

Met een SSD moet je inderdaad keuzes maken met wat je wel en niet op de SSD zet. Aan de andere kant kan ik mij niet voorstellen dat je al die spellen van die 455GB constant speelt.

Ik draai hier met een Crucial M4 128GB waar Windows en alle programma's opstaan. Momenteel staan daar 5 spellen op die ik regelmatig speel en heb ik nog 27GB vrij. Als ik ruimte te kort kom gooi ik een spel weg wat ik niet vaak meer speel. Voorlopig ben ik nog wel even zoet met BF3 en die blijft er dan ook opstaan, de rest van de spellen speel ik amper.

Voor data opslag gebruik ik 2x 2TB WD Green's wat ruim voldoende is. De spellen die ik niet vaak speel draaien daar dan ook op.

[ Voor 20% gewijzigd door PilatuS op 16-11-2011 21:49 ]

[Verwijderd]

Jah dat is ook wel weer zo.
Ik zal alle voor en nadelen eens op een rijtje zetten, en als mijn stufi dan weer binnen is eens kijken voor een ssdtje.

[THE_FIREFOX]

Welke windows draai je eigenlijk ? Als je vista draait is de max score die je per onderdeel kan halen namelijk 5.9

[Verwijderd]

Windows 7 64Bit professional
Ik zie trouwens ook net dat het een sata 300 aansluiting is.

Nouja ik denk dat ik er wel uit ben.
Misschien is er zo rond kerst een leuke aanbieding.

Bedankt allen.
Bas.

[ Voor 88% gewijzigd door Verwijderd op 16-11-2011 22:07 ]

[Verwijderd]

Wat een onzin weer in deze thread. Kennelijk is er nog zoveel onbekend over storage, terwijl ik dit voor mijn gevoel al jarenlang roep. Maar oke, nogmaals:

• Lage rpm schijven zijn de bom, hoge rpm is ouderwets. Hoge rpm zorgt voor met name hogere random IOps performance; dat is totaal irrelevant geworden nu er SSDs zijn die dit 100 tot 1000 (duizend keer = 100000%) sneller kunnen doen. 60IOps versus 70.000 IOps wat wil je daar nou mee doen? Leuk met je 7200rpm of 15000rpm dat maakt geen flikker uit. Dus kan met die onzin. Hoge rpm is nauwelijks sneller dan 5400rpm-class. 10 tot 20 procent waar zeuren we om? Een Samsung F4EG doet 140MB/s terwijl 7200rpm doorgaans zelfs minder dan dat halen; voor opslag is 5400rpm gewoon dé keuze.
• Green drives zijn voor hippies, green is dom, green is langzaam, green is niet bedoeld voor RAID. Allemaal bullshit natuurlijk. Dat WD Green niet voor RAID geschikt zouden zijn komt enkel omdat NIEUWERE type WD Green schijven geen TLER ondersteunen terwijl oudere WD20EADS Green schijven wél TLER ondersteunden. Western Digital wil je dat je twee keer zoveel betaalt voor een softwarefeature, in feite een bugfix voor ouderwetse domme RAID engines die geen onderscheid kunnen maken tussen schijven die met een bad sector recovery bezig zijn of schijven die het loodje hebben gelegd. Dus voor een bugfix betaal je het dubbele voor je hardeschijven. Gekker moet het niet worden. Niet voor RAID geschikt mijn aars. Dat is wat zij je willen doen geloven, zodat jij even dubbel neertelt voor hardeschijven, wat een foute humor!
• "Heb ook 5.9 met dezelfde hdd`s in raid-0, maar wpi is kut, kijk gewoon naar een echte benchmark!". Valt wat voor te zeggen. Zelf denk ik dat WEI best goed is. 5,9 is de maximale score die mechanische hardeschijven kunnen behalen, tenzij je Windows Experience Index om te tuin leidt bijvoorbeeld met Intel Volume write-back caching optie. De gedachte hierachter is dat hardeschijven altijd hoge seektimes hebben en een hoge doorvoer uiteindelijk de 'ervaring' toch bottleneckt omdat je nog steeds met hoge seektimes zit. Een SSD is dus per definitie beter dan een miljard hardeschijven in RAID0, omdat je applicaties sneller opstarten en het hele systeem gewoon veel sneller reageert, in tegenstelling tot de lage random read IOps van hardeschijven, in RAID of niet.
• "WD Caviar Green schijven zijn ook bedoelt als stille, koele en zuinige opslag. Echt snel zijn ze niet." Zijn prima snelle schijven. Moderne opslag. WD is wel langzamer dan Samsung. Het is niet voor niets dat de meeste gevaarlijke concurrenten Samsung en Hitachi zijn uitgeschakeld door Seagate en WD. Minder concurrentie = minder innovatie = minder investeringen = betere winstmarge = slechter voor de consument.
• "Koop een SSD, de goedkoopste (momenteel OCZ Vertex PLUS) zal je al verbaast doen staan!" OCZ/Sandforce SSDs moet je natuurlijk niet kopen, onbetrouwbare dure zooi. Je geeft tweehonderd ballen uit dan wil je toch een stuk techniek hebben wat normaal correct functioneert?! Marvell (Crucial M4) of Intel 320 zijn de juiste keuzes, eventueel een Samsung 830 al heeft die zich nog minder bewezen. Andere keuzes zijn min of meer inferieur. Al is dat misschien kort door de bocht, in zo'n bui ben ik nu eenmaal zeker gezien dit topic.
• "Ik zie trouwens ook net dat het een sata 300 aansluiting is." Ja voor hardeschijven heeft SATA/600 echt zoveel toevoeging. NOT. Dat is ook weer pure marketing. Hardeschijven met SATA/600 aansluiting en consumenten maar denken dat dat weer tig keer beter is.

Kortom: laat je toch niet zo misleiden. Koop een SSD voor je systeem (Windows+Apps) en 5400rpm schijven voor opslag, eventueel in RAID dat is prima. TLER schijven wil je niet dan kun je 10 keer beter in een backup investeren of nog beter naar professionele opslag zoals een ZFS NAS gaan kijken. Wat minder gevoelig worden voor marketing is ook geen slecht advies, lijkt mij zo.

Zo dat lucht op...

[Swordlord]

Denk aan je bloeddruk
Maar gelijk heb je wel...

[Verwijderd]

Ja gelijk even mijn pilletjes innemen, moet nog langer mee dan vandaag.

Toch neem ik de doorsnee tweaker niet kwalijk; er is immers zoveel misleiding en fabrikanten liegen vaak nét niet, maar impliceren wel dingen die niet waar zijn. Ze sturen je naar een bepaald denkpatroon wat hen goed uitkomt. Als consument moet je hier bedacht op zijn en kritisch deze denkpatronen bestuderen en objectief vaststellen hoe de vork in de steel zit. Dat is niet altijd even makkelijk, als je maar weinig objectieve onpartijdige bronnen hebt om je op te baseren.

Dat verhaal over WD Green is niet geschikt voor RAID bijvoorbeeld. Fabrikanten hebben er natuurlijk alle belang bij dat je 2 keer zoveel uitgeeft aan de dure RAID edition schijven. Goed je krijgt ook 2 jaar extra garantie, maar je betaalt daar wel enorm voor. Voornamelijk omdat deze schijven de TLER feature krijgen en normale desktopschijven niet. Dit terwijl de schijven fysiek hetzelfde zijn, alleen de firmware verschilt. Wat je eerst nog gratis krijgt (TLER) moet je nu heftig voor betalen; die RAID edition schijven zijn tegenwoordig 2 keer zo duur. Zo behalen hardeschijffabrikanten hedendaags hun winst denk ik dan ook, want voor 58 euro voor 2TB schijven kan ik me voorstellen dat de marges erg karig zijn.

Maar als consument moet je hier doorheen prikken, en betrouwbare inzichten verzamelen die toepasbaar zijn op jouw situatie en de objectief juiste keuze maken. Dat is vaak 180 graden anders dan de fabrikant graag wilt, omdat zij een belang hebben om je weinig te leveren terwijl je er wel veel (teveel) voor betaalt.

[Verwijderd]

Zo,
Dat is best veel informatie op da late avond
Klinkt ook allemaal heel interessant.
Ik denk ook dat ik dat ga doen. Gewoon een ssd voor mijn systeem en dan de schijven die ik nu heb voor opslag, muziek/ mijn documenten,weinig gebruikte en lichte apps.
Zoals ik uit je post kan halen zijn Marvell (Crucial M4) of Intel 320 goede keuzes en zal ik er ook zeker naar kijken.

Ik vraag me trouwens af hoe wpi het gaat doen als de hardware een stuk verder is.
Krijgt dan iedereen standaard een 10?

Zelf ben ik een elektronica man.
en kan ik me dus zeer goed voorstellen dat ssd velen male sneller is dan meerdere schijven in raid0.

Conclusie,
Ik blijf lekker zo draaien tot ik een leuke ssd tegen kom.

[Verwijderd]

Ik vraag me trouwens af hoe wpi het gaat doen als de hardware een stuk verder is.
Krijgt dan iedereen standaard een 10?

Hardeschijven lopen al tijden tegen theoretische beperkingen aan. De doorvoersnelheid is nog wel redelijk hoog, zeker voor een op mechanische techniek gebaseerd product. Maar een computersysteem leunt ook voornamelijk op random read performance en dat is gewoon beroerd bij elke hardeschijf. Met 0,4MB/s haal je het gewoon niet, tegen de kracht van SSDs op dit vlak. Daat komt dan ook de grote performancewinst vandaan.

Daarnaast, dit is de huidige situatie. Wil je 10 jaar verder kijken dan zijn hardeschijven totaal ongeschikt als systeemschijf alleen nog voor massaopslag. SSDs zijn dan vaste kost voor je OS+apps. En veel mensen hebben geen HDD meer nodig gezien de prijzen van SSDs. Een SSD heeft theoretisch vele meer mogelijkheden voor performacne scaling. Een HDD is theoretisch/fysiek beperkt door zijn mechanische componenten. Het enige wat ze kunnen doen is de rpm verhogen (ten koste van complexiteit/betrouwbaarheid/prijs/energieverbruik) en de datadichtheid verhogen. Dat laatste is eigenlijk de enige manier voor HDDs om sneller te worden, maar dat gaat in een slakkentempo.

Daarnaast zakt de prijs per gigabyte voor schijven maar redelijk traag, terwijl solid state opslagtechniek in rap tempo goedkoper wordt. Eens is het omslagpunt en dat punt benaderen we al over een paar jaar mogelijk. Dat betekent niet dat per gigabyte SSDs goedkoper zijn dan HDDs, dat zal voorlopig nog niet gebeuren. Maar wel dat de prijs per gigabyte voor SSDs hard gaat zakken tot het punt dat een HDD niet meer nodig is voor 90% van alle consumenten. Dan kom je opeens in een spiraal terecht waarbij hardeschijven veel duurder worden gezien de lagere afzet en dus productie, terwijl SSDs steeds goedkoper worden door de groeiende vraag en dus groeiende productiecapaciteit.

Hoe het landschap over 10 jaar zal zijn is enigszins onduidelijk, maar ik denk dat hardeschijffabrikanten het moeilijk hebben. Nu hebben ze even een leuke periode door de hogere prijzen (overstromingen) maar je ziet nu al dat de twee beste (meest innoverende) hardeschijffabrikanten worden opgekocht en er feitelijk maar twee echte bedrijven overblijven. Daarnaast daalt de vraag en productie van desktopschijven al enige tijd, alleen van notebookschijven stijgt deze nog. Het keerpunt is eigenlijk al bereikt. HDD techniek heeft zijn laatste fase bereikt en zal krimpen, terwijl SSD techniek nu pas tot bloei komt.

Qua SSDs zitten we nu nog met NAND wat problemen geeft omdat bestaande beschreven blokken niet overschreven kunnen worden. Dit betekent dat SSDs erg traag zijn tenzij controllers aan write remapping doen en dus data elders schrijven dan de host eigenlijk wilt. Dit zorgt voor allerlei extra complexiteit en dus ook bugs en performancedegradatie. Bij nieuwere technieken als PCM (Phase-Change Memory) is dit probleem afwezig en kunnen er dus simpelere controllers ontwikkeld worden wat de prijs, betrouwbaarheid en beschikbaarheid ten goede komt. Over 10 jaar met PCM is het denk ik dan ook redelijk snel afgelopen met het imperium van hardeschijven, die dan als nichemarkt doorgaan wellicht tot 2030 ofzo. Maar vanaf 2016-2020 is voor veel consumenten een HDD al verleden tijd. 90% zal dan enkel SSDs gebruiken, zo is mijn verwachting.

[Madrox]

Twee disk in raid-0 doet het niet voor mij: winst is te beperkt en soms zelfs onder nul (uitpak/kopieer acties).
Daar je met twee losse single disk sneller kan uitpakken kopieren dan met raid schrijven en lezen tegelijk.

Heb zes WD Blue's in RAID-5 en die halen hogere read writes dan mijn IntelPostville SSD. Behalve met kleine bestandjes, daar is de SSD heer en meester.

Een goede 7200rpm schrijf is wel degelijk sneller, zie ook hier:
http://www.legitreviews.com/article/1442/10/
hier
http://www.hardwarecanuck...hard-drive-review-11.html
of hier
http://www.tomshardware.c...tb-hdd-caviar,2261-8.html

Zou zelf nooit 5400rpm disks in mijn raid setup willen. De Blue's zijn sneller en bevallen qua hitte en geluid prima!

Je slikt de foute pillen, vriend

ps: de Wd Blue ondersteunt ook geen TLER, desondanks draaien ze alle zes hier al twee jr zonder problemen in een RAID-5 config, 24/7.

http://www.smallnetbuilde...r-drives-in-your-raid-nas
Het nut van tler word hier afgemeten en de reviewer stelt dat een robuuste harddisk constructie nog altijd meer zekerheid bied dan TLER.

[ Voor 30% gewijzigd door Madrox op 17-11-2011 04:24 ]

[rookie no. 1]

Toch even een aanvulling op die (specifieke) Green schijven van WD: het is niet voor niets dat veel NAS leveranciers die dingen adviseren ze niet te gebruiken in RAID-setups, want ze zorgen bij veel gebruikers tot een instabiele RAID-set.

Uiteraard hoort hierbij niet de hele Green-lijn van alle fabrikanten over één kam geschoren te worden

Dat verhaal over hoge of lage RPM's mag ook wel wat meer nuance krijgen, want hoge RPM maakt zeker wel uit alleen maakt het uit waar je de storage voor gebruikt. Een database server of veel gebruikte file-server heeft toch écht wel voordelen aan hoge RPM's. Ik kan me nog goed de frustraties herinneren van gebruikte RAID-sets met 7200RPM disks en na vervanging van met 10000RPM of zelfs 15000RPM disks opgelost.

Puur storage en weinig gelijktijdig gebruik: 5400/5900RPM prima.

Over die SSD's: jawel, Sandforce controllers zeker vermijden, maar om nou gelijk te zeggen dat voor het geld en snelheidsgevoel de OCZ Vertex Plus ook maar aan de kant gezet moet worden, vind ik te ver gaan. Voor mensen met weinig budget (er zijn ook mensen die buiten de IT werken en geen dik salaris hebben), is dat toch een al te redelijke keuze.


Maar goed...volgens is de TS al geholpen en daar ging het om

P.s.: Overigens respect voor je toewijding aan de vele SSD/HDD topics. Ik waardeer je kennis en wil om iedereen juist te informeren/helpen!

[M2M]

Liever geen raid eigenlijk voor traditionele harde schijven. Gewoon een stel disks. Waarom? Raid0 doet enkel de sequentiele throughput verhogen. edit: fout. Zie hieronder! Maar je zit al met 100+ MB/s. 200MB/s maakt voor het opstarten van je applicaties of het pompen van data over een netwerk echt geen verschil. (de 1% die een getrunkt stel gigabit aansluitingen heeft uitgesloten). Bovendien heeft een beetje SSD, de limiet van de interface te pakken. Je zult dan aardig wat harde schijven in raid0 moeten plaatsen om dat te overtreffen.

Daarnaast hebben we nog raid1. Is geen backup. Stroompiekje en je bent alsnog vele euro's kwijt om je data door een professioneel bedrijf van de harde schijf te halen. Backups doe je normaliter op een externe locatie. Gooi een externe schijf bij (schoon)ouders en elke keer als je daar op bezoek gaat sync je de boel even.
Online opslag in een cloud of elders op een servertje werkt ook prima. En zoveel data hoeft er niet gebackupped te worden. Persoonlijke foto's e.d. en daar houdt het op. Alles wat van internet te plukken is, behoeft geen backup.

[Swordlord]

M2M schreef op donderdag 17 november 2011 @ 12:13:
Liever geen raid eigenlijk voor traditionele harde schijven. Gewoon een stel disks. Waarom? Raid0 doet enkel de sequentiele throughput verhogen.

Een RAID0 doet veel meer dan alleen de sequentiële throughput verhogen.

Zodra er wordt gewerkt met hogere queue depths, dus veel requests, dan worden de acces times drastisch verlaagd, omdat gelijktijdig meer data opgezocht kan worden.

De verschillende stukken data zouden verspreid kunnen staat over verschillende drives, waardoor dus elke drive alleen zijn eigen rotatietraagheid eenmalig heeft, voor 1 specifieke request en niet een opeenstapelende traagheid omdat hij constant met de leeskop over de platter moet heen en weer zwaaien om te voldoen aan alle requests.
Dit is een enorme verhoging in de random IOP, daarom word RAID0 (en varianten) toegepast in database omgevingen.

Dat op sequentieel vlak het effect het makkelijkst te meten is, is overduidelijk, maar random IOPS schalen net zo goed mee met het aantal drives bij een RAID-0

Edit:

RAID0 Scaling: Queue Depth / Aantal drives
http://www.tomshardware.c...ALING-CHARTS,1635-11.html

[ Voor 23% gewijzigd door Swordlord op 17-11-2011 12:42 ]

[GH45T]

Enkele jaren geleden had ik een zestal 10.000 rpm scsi harde schijven in RAID0 in mijn PC zitten, puur voor de snelheid.

Toen iets minder dan 2 jaar gelden de SSD's onder de € 2,- per GB kwamen heb ik een 120GB OCZ Solid2 gekocht voor mijn PC en de RAID set er uit gehaald.

Een performancewinst! Ongeloofelijk. Sequentieel was de SCSI RAID wel sneller, maar voor desktopgebruik (starten applicaties en dergelijke) is de enkele SSD veel sneller. Dezelfde SSD zit nog altijd in mijn PC en bevalt nog altijd prima. Natuurlijk, er zijn inmiddels weer veel snellere exemplaren verkrijgbaar en de kosten per GB vallen mij alleszins mee. De nood om te upgraden is er echter niet, mijn Indilinx Barefoot based SSD voldoet voor mij prima.

[M2M]

Swordlord schreef op donderdag 17 november 2011 @ 12:30:
[...]


Een RAID0 doet veel meer dan alleen de sequentiële throughput verhogen.

Zodra er wordt gewerkt met hogere queue depths, dus veel requests, dan worden de acces times drastisch verlaagd, omdat gelijktijdig meer data opgezocht kan worden.

De verschillende stukken data zouden verspreid kunnen staat over verschillende drives, waardoor dus elke drive alleen zijn eigen rotatietraagheid eenmalig heeft, voor 1 specifieke request en niet een opeenstapelende traagheid omdat hij constant met de leeskop over de platter moet heen en weer zwaaien om te voldoen aan alle requests.
Dit is een enorme verhoging in de random IOP, daarom word RAID0 (en varianten) toegepast in database omgevingen.

Dat op sequentieel vlak het effect het makkelijkst te meten is, is overduidelijk, maar random IOPS schalen net zo goed mee met het aantal drives bij een RAID-0

Edit:
Veel plezier met dit lezen.
http://www.tomshardware.c...ALING-CHARTS,1635-11.html

dus we gaan van 60 IOPS naar 120 IOPS in raid0? en van 400 kilobyte per seconde naar 800 KB/s. Prima als jij dat genoeg vind. Ik schaf liever een SSD aan.

Bovendien wordt er in je linkje serverhardware gebruikt. In combinatie met een fatsoenlijke driver en degelijke stripe alignment. op een Areca ARC-1220 notabene. Dat is geen consumentenhardware.

Dus daarom is mijn advies om lekker alle raid vormen te laten liggen. Gewoon een stel disks, desnoods in JBOD. Gaat er eentje stuk dan is het een kwestie van backups terug zetten.

[Swordlord]

Jij sprak over RAID0 performance in het algemeen...

Raid0 doet enkel de sequentiële throughput verhogen.

SSD is beter in random IOPS, goh dat is bekend.

Het is een Areca controller, wat dan nog? Het is nog steeds RAID0 waar we het over hebben en schijnbaar schaalt de random IOPS mee...
Jij claimde dat dit niet gebeurde bij een raid 0 en toch gebeurd het daar... Leg uit?

Je advies heeft wel een waarheid, voor consumenten is een HDD raid0 minder handig, maar de functionaliteit is niet opeens anders is voor consumenten.

[ Voor 36% gewijzigd door Swordlord op 17-11-2011 12:57 ]

[M2M]

gecorrigeerd.

[Verwijderd]

Madrox schreef op donderdag 17 november 2011 @ 04:10:
Twee disk in raid-0 doet het niet voor mij: winst is te beperkt en soms zelfs onder nul (uitpak/kopieer acties).

RAID0 performance kan eigenlijk nooit negatief zijn. Er zijn wel uitzonderingen, zoals een slechte setup met misalignment en een te kleine stripesize (<128KiB), waarbij een read meerdere disks meeneemt en zo de access time verhoogt wordt doordat je op de rotational delay van twee schijven ipv één schijf moet wachten, wat gemiddeld gezien dus hoger dan de helft van de rotational delay bedraagt, tot een maximum van één hele rotational delay bij meerdere schijven.

Daar je met twee losse single disk sneller kan uitpakken kopieren dan met raid schrijven en lezen tegelijk.

Daar heb je natuurlijk gelijk in. Maar of dat praktisch is? Als je een ingepakt bestand downloadt, dan wil je die vaak naar dezelfde schijf uitpakken. Sommige mensen gaan speciaal voor het performancevoordeel een speciale hardeschijf voor downloads maken en de ander om naar uit te pakken, maar ik schat dat maar heel weinig gebruikers dat zo doen.

Een goede 7200rpm schrijf is wel degelijk sneller, zie ook hier:
http://www.legitreviews.com/article/1442/10/
hier
http://www.hardwarecanuck...hard-drive-review-11.html
of hier
http://www.tomshardware.c...tb-hdd-caviar,2261-8.html

De eerste review gaat over de 3TB WD Green, die stukken trager is dan een 2TB Samsung F4EG of de 2TB WD Green.

De middelste review gaat over XP boot performance. Het zou prima kunnen dat ze een XP partitie gebruiken en dat betekent misalignment. Dit veroorzaakt lagere performance bij 4K sector schijven zoals de WD20EARS, maar normale oudere schijven hebben hier geen last van. Wel zijn hogere rpm schijven beter bij dit type workloads, maar daar mag je tegenover zetten dat Windows sinds Vista een feature genaamd SuperFetch gebruikt, die tijdens de boot in plaats van random reads één groot bestand laat inlezen. Dit zorgt ervoor dat lage rpm schijven en hardeschijven in het algemeen niet meer hoeven te doen waar ze heel slecht in zijn: random I/O. Want elke hardeschijf doet het erg slecht op het gebied van random reads.

De laatste review van tom is wel aardig, maar wel de oudere 500GB-platter WD Green. Tegenwoordig zitten we met 666GB - 1TB platter schijven. Maar de scores van die review kloppen wel aardig, al is PCMark niet zo'n heel goede benchmark naar mijn smaak.

Zou zelf nooit 5400rpm disks in mijn raid setup willen. De Blue's zijn sneller en bevallen qua hitte en geluid prima!

Dan blijf je daar fijn bij. Dat doet verder niets af aan mijn verhaal. De green schijven zijn qua sequential I/O ijzersterk en nauwelijks minder goed dan ouderwetse hoge rpm schijven, zoals jouw WD Blue. Heb je geen SSD en gebruik je een ouderwets OS zoals XP dan biedt een hogere rpm schijf nog wel meerwaarde. Maar dat zijn tegenwoordig steeds zeldzamere situaties. Moderne versies van Windows hebben geprobeerd om onder de nadelen van mechanische schijven uit te komen door ze minder random I/O te laten doen.

De beste situatie is dat je een SSD gebruikt in combinatie met een HDD. De SSD doet dan zaken als OS/applicatie I/O terwijl de hardeschijf grote bestanden opslaat. Voornamelijk in deze configuratie komen green schijven tot hun recht en is er eigenlijk geen verschil meer tussen de twee. Ook de SRT techniek van Intel waarbij een SSD als cache dient voor een grote hardeschijf, is bij uitstek geschikt voor lage rpm schijven. Deze concentreren zich dan op sequential I/O terwijl de random I/O gedaan wordt door de SSD. Dit combineert de beste eigenschappen van zowel HDD als SSD.

ps: de Wd Blue ondersteunt ook geen TLER, desondanks draaien ze alle zes hier al twee jr zonder problemen in een RAID-5 config, 24/7.

RAID5 is natuurlijk sowieso al slecht, en zonder TLER is de kans op problemen bij hoge capaciteit schijven zeker aanwezig. Dat je nu nog geen problemen hebt ondervonden, betekent niet dat je die nooit krijgt. Kijk bijvoorbeeld eens naar je SMART output, zie je daar Current Pending Sector of Reallocated Sector Count staan met een waarde hoger dan 0? Zo nee, dan heb je simpelweg nog nooit error recovery hoeven te doen waarbij TLER een rol speelt.

http://www.smallnetbuilde...r-drives-in-your-raid-nas
Het nut van tler word hier afgemeten en de reviewer stelt dat een robuuste harddisk constructie nog altijd meer zekerheid bied dan TLER.

Wel een aardig artikel dat het goed probeert uit te leggen, maar er staan welke enkele foute aannames in:

In RAID applications, however, you do have redundant data, which the RAID controller is managing. So if a drive takes too long handling a bad block, at some point the RAID controller will go read / write the data from another drive. The key point here is what it does with the drive that didn't respond in time.

Dat kan een controller altijd al natuurlijk. Het kan zelf de schijf met rust laten en simpelweg de data van andere schijven (parity) inlezen en dat naar de applicatie sturen. Beter nog, het kan de betreffende data weer schrijven naar de schijf die een bad sector had, zodat de schade direct wordt gerepareerd. Als RAID engines dit zouden doen, zouden ze helemaal geen TLER nodig hebben. Alleen het geavanceerde ZFS doet wat ik hierboven beschrijf; automatisch bad sectors repareren door redundante data naar de bad sector te schrijven, zodat de hardeschijf de bad sector om kan wisselen voor een reserve sector. Helaas is ZFS hier een uitzondering in.

Het punt is natuurlijk dat conventionele RAID engines niet goed omgaan met hoge timeouts van disks. In feite is TLER dus een bugfix of workaround. Het echte probleem is de absurde implementatie van RAID engines die een hele schijf als failed beschouwen omdat één klein sectortje niet gelezen kan worden. Bad design.

The responses I received from Synology, QNAP, NETGEAR and Buffalo all indicated that their NAS RAID controllers don't depend on or even listen to TLER, CCTL, ERC or any other similar error recovery signal from their drives. Instead, their software RAID controllers have their own criteria for drive timeouts, retries and when a drive is finally marked bad.

Ook dit is fout gedrag omdat de hele schijf dus bad/failed wordt beschouwd terwijl het vrijwel altijd om losse bad sectors gaat terwijl de schijf zelf nog prima is. Toch wordt dan de hele schijf als failed beschouwd, wat een slecht design is.

Daarnaast, TLER is geen signaal wat van de schijf naar de controller wordt gestuurd; de controller weet helemaal niets over TLER. TLER wil simpelweg zeggen dat een hardeschijf na 7 seconden gewoon opgeeft met recovery en een I/O error terugstuurt in plaats van blijven proberen de bad sector te recoveren. Of je nou de schijf in RAID hebt of niet maakt niet uit; TLER is een drive setting waar de controller zelf geen weet van heeft.

These software RAID controllers are generally more patient and wait significantly longer for drive response and execute more retries before finally giving up and marking a drive dead. While this may degrade performance slightly when dealing with drives with bad blocks, it's intended to reduce the occurrances of drives dropping out of RAID volumes and the subsequent long, risky rebuilds.

Leuk gedacht en je kan wel drie miljard retries doen, maar als een bad sector echt bad is, moet je dat anders oplossen zoals ZFS het doet. Je blijft met een schijf waar alle 2 miljoen sectoren leesbaar zijn maar één kleine sector niet. Dit terwjil je binnen een seconde alle problemen kan oplossen door met redundante data de bad sector te overschrijven. Dat doen deze inferieure implementaties niet en dan krijg je dus veel gezeik.

I say "risky" because rebuilds take many hours and sometimes days for the large 4TB+ volumes possible with today's even medium-range NASes. And every second that an array is rebuilding is a chance for one more error that will kill the entire volume.

Hier slaat hij ook de spijker op de kop. Tijdens een rebuild die vaak moet gebeuren doordat schijven uit de array geschopt worden, is je array enorm kwetsbaar. Wat nu als op een andere schijf tijdens de rebuild opeens weer een bad sector voorkomt? Dan heb je een groot probleem want dan gooit de controller ook deze schijf uit de array. Met RAID5 betekent dat een failed array met dit soort domme controllers, ook al zijn maar twee kleine blokjes van 512 bytes onleesbaar en de rest allemaal intact, toch is je array dan failed en kun je alleen met handmatige recovery je data nog terughalen, wat velen niet weten of niet de kennis/geduld voor hebben. Fail.


Oh en die pillen doen goed hun werk hoor, anders had ik nooit zo rustig op jouw berichtje kunnen reageren.

[Verwijderd]

rookie no. 1 schreef op donderdag 17 november 2011 @ 12:01:
Toch even een aanvulling op die (specifieke) Green schijven van WD: het is niet voor niets dat veel NAS leveranciers die dingen adviseren ze niet te gebruiken in RAID-setups, want ze zorgen bij veel gebruikers tot een instabiele RAID-set.

Door een fout design in de RAID engine, niet door de schijven zelf. Heeft ook niets met green of rpm te maken, maar met de afwezigheid van TRIM. Oudere green schijven (vroegere WD20EADS) hadden overigens wel TRIM. Totdat het WD wel geinig leek om deze feature exclusief voor RAID edition schijven te houden en daar twee keer zoveel geld voor te vragen, omdat er nu eenmaal heel veel slechte RAID engines zijn die vreselijk slecht met disk timeouts omgaan.

Uiteraard hoort hierbij niet de hele Green-lijn van alle fabrikanten over één kam geschoren te worden

Dat wordt wel gedaan. Green is slecht, green is langzaam, green is voor hippies... Lage rpm heeft een slechte reputatie. Ik hoop die enigszins recht te kunnen zetten. Lage rpm is de bom tegenwoordig, want wat hoge rpm schijven kunnen, doen SSDs 100 tot 1000 keer beter. Blijft over massaopslag waar lage rpm schijven bij uitstek geschikt voor zijn. Samsung F4EG met 140MB/s max sequential I/O is daar een goed voorbeeld van.

Dat verhaal over hoge of lage RPM's mag ook wel wat meer nuance krijgen, want hoge RPM maakt zeker wel uit alleen maakt het uit waar je de storage voor gebruikt. Een database server of veel gebruikte file-server heeft toch écht wel voordelen aan hoge RPM's.

Vroeger moesten database servers (zoals die van tweakers.net) inderdaad op mechanische techniek vertrouwen. En dan zit je dus met dure krengen die op 15 duizend toeren draaien, enorm veel energie verbruiken, en net 2x sneller random IOps doen dan 5400rpm spchijven. Waaaauw!

Gelukkig zijn gebruikers die random I/O performance nodig hebben, zoals eigenaren van database servers, nu verlost van deze mechanische techniek en kunnen nu SSDs inzetten die 35.000 tot 70.000 IOps doen per stuk, in plaats van 60 tot 200 IOps. En dat tegen 100 keer minder energie, kleiner formaat, geen vibraties, geen koeling nodig en potentiëel een betere levensduur cq betrouwbaarheid.

Over die SSD's: jawel, Sandforce controllers zeker vermijden, maar om nou gelijk te zeggen dat voor het geld en snelheidsgevoel de OCZ Vertex Plus ook maar aan de kant gezet moet worden, vind ik te ver gaan. Voor mensen met weinig budget (er zijn ook mensen die buiten de IT werken en geen dik salaris hebben), is dat toch een al te redelijke keuze.

Qua snelheid is de OCZ Vertex Plus prima, zelfs een relatief slechte SSD als Indilinx kan je ervaring vergeleken met een HDD als systeemschijf enorm doen verbeteren. Maar de prijs is maar 10 of 20% lager dan dat van een echt goede SSD, zoals de Crucial M4. Dus of je er nou echt goed aan doet om zo te bezuinigen op een goede controller?

Ik vind het daarnaast ook zonde om duur NAND geheugen dan te koppelen met een slechte/minder goede controller, die maar een deel van de totaalprijs uitmaakt. Als je veel gezeik hebt met je SSD, is die investering er niet een waar je zoveel plezier van hebt. Terwijl je voor een tientje of twee meer die ervaring wél zou moeten hebben. In dat opzicht ben ik erg kritisch over goedkope SSDs met controllers als Sandforce, Indilinx, JMicron en in mindere mate Toshiba. Ze zijn inderdaad iets goedkoper, maar is dat het waard? Het is niet alsof goede SSDs opeens twee keer zo duur zijn ofzo.

P.s.: Overigens respect voor je toewijding aan de vele SSD/HDD topics. Ik waardeer je kennis en wil om iedereen juist te informeren/helpen!

Dank voor je compliment. Helaas ben ik wel van het type dat een afwijkende mening heeft, die ingaat tegen de status quo; de standaardmening op het web die duizend keer herhaald wordt maar in feite onjuist is. Vooral over storage zijn er enorm veel fabeltjes of foute analyses. Hopelijk mag ik dit topic gebruiken om een poging te doen deze te doorbreken.

[Verwijderd]

Oké laatste opmerking...

M2M schreef op donderdag 17 november 2011 @ 12:13:
Liever geen raid eigenlijk voor traditionele harde schijven. Gewoon een stel disks. Waarom? Raid0 doet enkel de sequentiele throughput verhogen. edit: fout. Zie hieronder! Maar je zit al met 100+ MB/s. 200MB/s maakt voor het opstarten van je applicaties of het pompen van data over een netwerk echt geen verschil. (de 1% die een getrunkt stel gigabit aansluitingen heeft uitgesloten). Bovendien heeft een beetje SSD, de limiet van de interface te pakken. Je zult dan aardig wat harde schijven in raid0 moeten plaatsen om dat te overtreffen.

Zo grappig is dit! Veel mensen weten namelijk niet dat een SSD zijn hoge snelheden haalt door kanalen van 30MB/s in RAID0 te plaatsen (eigenlijk een RAID4 of RAID5 maar dat is een ander verhaal).

Je kunt met benchmarks als CrystalDiskMark en AS SSD heel duidelijk het effect van RAID0 zien. Neem een standaard benchmark:



Je ziet hier duidelijk dat de 4K random read performance vrij laag is; altijd zo rond de 20MB/s. Dat is omdat bij dit type workload er geen gebruik kan worden gemaakt van de striping (RAID0) techniek. De SSD kan hierdoor maar één kanaal tegelijk gebruiken. Ga je de queue depth omhoog gooien waardoor de SSD tot 32 verzoeken tegelijk ontvangt voor random reads, dan kan het wel alle kanalen verzadigen, waardoor je grofweg 10 keer zo hoge random read scores haalt.

Alleen bij 4K random read zie je dit fenomeen, omdat random read de enige workload zijn die RAID0 niet of nauwelijks kan versnellen. Alleen bij een hogere queue depth, valt er winst te behalen. Bij random write is een hogere queue depth niet nodig, omdat writes gebuffered worden. Integenstelling tot reads hoeft er niet gewacht te worden totdat de write helemaal is weggeschreven. Door disk buffering zal de SSD zeggen dat de write al voltooid is, terwijl hij nog gewoon in DRAM/SRAM cache geheugen staat. De host zal hierdoor al een nieuwe write kunnen sturen terwijl de eerste nog niet verwerkt is. In de praktijk betekent het gewoon dat writes masaal naar de SSD gepompt worden en de latencies heel laag kunnen zijn. Dit heeft tot gevolg dat de RAID0-achtige structuur van SSDs bij random writes goed benut kunnen worden zelfs met een queue depth van 1. Overigens is de efficiency vaak wel beter bij een queue depth van 2 tot 4. Hoger heb je niet echt nodig.

Bij sequential read en sequential write is RAID0 altijd heer en meester. Dit omdat de disk zelf kan voorspellen wat het moet gaan doen. Als jij blok 1, 2, 3 en 4 leest, zal de disk alvast doorgaan en blokken 5 en 6 en 7 inlezen. Zodoende kan er bij sequential read altijd gebruik gemaakt worden van de voordelen van RAID0. Bij writes gaat het buffering principe op zoals hierboven beschreven.

Kortom, een SSD dankt zijn hoge snelheid aan RAID0. Eén SSD is in feite een 8 tot 10 kanaals RAID0. Dat kun je ook terugvinden in het performancekarakter van de SSD.

Zou je 10 green hardeschijven in RAID0 plaatsen, zit je theoretisch aan 1,4GB/s. Wel schalen hardeschijven stukken minder goed dan SSDs omdat ze enorm veel afgerem kunnen worden door wat random I/O tusendoor. Zolang alle disk members worden voorzien van werk heb je perfecte schaling. Zou je dus eerlijk vergelijken 1-kanaals SSD versus HDD of 10-kanaals SSD versus RAID0 van 10 hardeschijven, dan zie je duidelijk dat hardeschijven qua sequential I/O het flink gaan winnen.

Daarom ook dat technieken als SRT (en L2ARC in ZFS) zo sexy zijn. Je kunt de beste eigenschappen van beide technieken combineren. De random I/O performance van SSDs met de sequential I/O performance van HDDs.

Amen.

[M2M]

dan mag je me nog een ding uitleggen. Voor zover ik raid0 begrepen heb, deel je de schijf in in kleine stukjes (stripe size). 8KB, 64 of 128 en nog wat meer waarden. Elke lees of schrijfactie die groter is dan zo'n klein stukje wordt verdeelt over de schijven in de raid config.

Als je dus stukjes van 4K gaat lezen zal je dus uitkomen op leesgroottes die kleiner zijn dan de stripe size. 4K random IO zonder queue depth zal 1 schijf tegelijk gelezen worden. Als je de queue depth verhoogt kan het leeswerk van een stukje op schijf 2 al beginnen als die van schijf 1 nog bezig is. Hoe meer schijven je hebt, hoe meer stukjes 4K leeswerk er tegelijk uitgevoerd kan worden.

Maar wat nu als je de stripe size kleiner maakt dan die 4K (theoretisch dan). Dus voor de grap stripe size op 1KB. Dan schaalt je IOPS dus niet meer tussen 1, 2 3 of 4 schijven in raid0.

Dus als je een standaard stripe size hebt van 64K, en je meet random IO op 128K, dan zul je geen scaling meer zien tussen 1, 2 of 3 schijven in IOPS.

Dit klopt toch?

edit: nu ik toch bezig ben, verhoogt raid1 dan ook de random IOPS 4K QD32 ten opzichte van een enkele schijf?

Verder wist ik wel dat SSD's hun sequentiele snelheid te danken hadden aan interne raid0. Wat ik nog niet wist is dat individuele kanalen binnen zo'n SSD eigenlijk niet zo'n geweldige IOPS (relatief t.o.v. het eindresultaat met wachtrij) kunnen leveren en dat dat verveelvoudigd kan worden als je er een queue tegenaan gooit. Weer wat geleerd

[ Voor 3% gewijzigd door M2M op 17-11-2011 17:59 ]

[Verwijderd]

Kijk dit soort dingen vind ik nou interessant om uit te leggen! Helaas komen dit soort onderwerpen niet meer zo vaak aan bod. Maar inmiddels heb ik genoeg ervaring met RAID performance om daar wat nuttigs over te mogen zeggen.

Op internet lees je vaak de gedachte over RAID0 performance: "mijn I/O request is 64 kilobyte, dus met 4 schijven moet ik dan 16KiB stripesize hebben zodat bij het lezen of schrijven van 64 kilobyte alle 4 de disks aan het werk gezet worden". Die gedachte klinkt heel logisch, maar is volkomen fout! Op die manier heb je namelijk wel winst met grote bestanden, maar 0,0 winst met random I/O performance.

Jij zegt het dus eigenlijk helemaal goed: als je stripesize te laag is, heb je geen of minder performance scaling. Dus hoe hoger de stripesize, des te beter voor random I/O. Des te lager de stripesize, des te beter voor sequential I/O omdat je filesystem dan minder read-ahead en write buffering hoeft te doen om alle disk members aan het werk te zetten. Dit is dus precies tegenovergesteld dan wat meestal gedacht wordt en door populaire websites ook verteld danwel geimpliceerd wordt.

Voor RAID0 en andere striping RAID (RAID4/5/6) wil je dus eigenlijk altijd een stripesize van 128KiB of hoger hebben. Een 16 kilobyte random read kan dan door disk1 worden afgehandel, terwijl andere read of writes die op dat moment klaarstaan door de andere disks kunnen worden afgehandeld. In de praktijk gebeurt het natuurlijk ook wel eens dat twee of meer I/O voor disk1 zijn bestemd, en niks voor disk2/3/4. In dat geval heb je tijdelijk geen winst, dus de performancewinst met RAID0 voor random I/O is geen 100%, maar theoretisch kan dat wel als de I/O precies goed wordt verdeeld.

Ik ben nu bezig met ZFSguru, een NAS project op basis van het ZFS filesystem wat je misschien wel kent. De ontwikkelaar hiervan heeft onder het FreeBSD/ZFSguru besturingssysteem wat benchmarks gedraait met de geom_stripe (RAID0) driver. Met name over het effect van stripesize op de random I/O performance. Hier kun je die resultaten zien:
http://submesa.com/data/raid/geom_stripe
http://submesa.com/data/raid/geom_stripe/page2

Zoals je ziet geldt voor random I/O dat de stripesize het beste lekker groot kan zijn. De test die hij gebruikt (raidtest) is wel een die op volkomen willekeurige blokken begint. Dus als een stripe 128KiB is en de I/O is 4 kilobyte, dan kan het zijn dat deze op 127.0K begint en op 131.0K eindigt, zodat er alsnog twee disks betrokken zijn (wat we niet willen). Dit is de reden dat bij deze benchmark de scores hoger worden naarmate de stripesize groter wordt, omdat bij een 1 megabyte stripesize de kans dat een I/O request overloopt over twee stripe blokken dan steeds kleiner wordt.

Conclusie: 128KiB als minimum stripesize hanteren, hoger kan nuttig zijn voor random IOps maar in veel gevallen hoeft dat niet, en hogere stripesize kan slecht zijn voor je sequential I/O.

edit: nu ik toch bezig ben, verhoogt raid1 dan ook de random IOPS 4K QD32 ten opzichte van een enkele schijf?

RAID1 zal nét iets trager zijn met random write. Maar voor random read IOps zal RAID1 beter zijn dan RAID0. Dit komt omdat bij RAID1 je aan ware load balancing kan doen. Je hebt immers niet meer het probleem bij RAID0 dat 4 requests voor disk1 zijn bestemd en 0 voor disk2. Bij mirroring kan de RAID engine zelf kiezen welke disk hij pakt. geom_mirror onder FreeBSD heeft een geavanceerd load balancing algoritme wat de disk met de minste belasting kiest. Dit zorgt ervoor dat je zonder veel problemen snellere en minder snelle disks kunt combineren, zodat de snellere disk meer reads krijgt te verwerken dan de langzamere disks.

Sequential read onder RAID1 is echter een ander verhaal; dat is veel moeilijker om in de buurt van RAID0 performance te komen. Dit komt omdat bij RAID1 je minder makkelijk I/O kunt splitsen. Pas je bijvoorbeeld een striping toe zoat disk1 128KiB leest en disk2 de volgende 128KiB block, dan betekent dit dat beide disks continu blokken moeten overslaan. Dat betekent dus ook maar dat ze 50% van hun sequential read performance halen, 50% x 2 = 100% = de performance van een enkele disk. Alleen als je hele grote blokken gebruikt, zal het overslaan veel minder vaak hoeven te gebeuren en kun je disks wel aardig aan het werk houden. Maar dat is problematisch en complex. ZFS doet RAID1 sequential read overigens wel erg goed, beter dan ik ooit heb gezien inclusief Areca RAID1 performance.

Verder wist ik wel dat SSD's hun sequentiele snelheid te danken hadden aan interne raid0. Wat ik nog niet wist is dat individuele kanalen binnen zo'n SSD eigenlijk niet zo'n geweldige IOPS (relatief t.o.v. het eindresultaat met wachtrij) kunnen leveren en dat dat verveelvoudigd kan worden als je er een queue tegenaan gooit.

Inderdaad. Voor random read heb je dus een hogere queue depth nodig. Dit werkt precies zo met software/hardware RAID0 op losse HDDs of SSDs. Voor random read moet je hogere queue depth hebben om profijt te hebben.

Maar voor writes is het anders. Bij een enkele queue depth kun je eigenlijk al alle disks aan het werk zetten, omdat je door gebruik van write-back de write requests kunt bufferen. Ook met qd=1 heb je dus in theorie al duizenden writes klaar staan die je optimaal kunt verdelen over de disks. In de praktijk zie je wel dat de efficiency toeneemt met een iets hogere queue depth (2/3/4) maar je hebt echt geen hoge queue depth nodig voor random writes om profijt van RAID0 te hebben.

Random read is dus erg afhankelijk van de queue depth, random write veel minder. Random writes komen ook meestal in burst voor. De metadata van je filesystem wordt vaak ook geupdate, dus maar heel zelden komen random writes met enkele queue depth voor.

[Verwijderd]

Fijn dat je de tijd neemt om het zo uitgebreid uit te leggen.
Ik zal het nog eens op mijn gemakje nalezen. (Best druk met een autotheorie examen voor de deur.)

Volgens mij staat mijn stripsize veel te laag, 4096 bytes.
Waar kan ik dit controleren, in de bios of kan het ook gewoon onder windows?
En het aanpassen, dan moet ik zeker formatteren?

Groeten,
Bas

[Verwijderd]

Stripesize veranderen betekent de RAID set verwijderen/vernietigen en opnieuw opbouwen inderdaad. Dus dat gaat niet zonder gegevensverlies.