2x goedkopere 128gb SSD's in RAID 0 VS. 1x goede 256GB SSD

[JT]

Voor een systeem ben ik aan het kijken naar een SSD voor opslag (i5 2400, 8gb RAM, zal 67/68 serie chipset mobo worden). Nu kwam ik op het idee dat ik misschien wel een RAID 0 setup kan nemen in de vorm van 2x128gb ipv 1x256gb Het is echter voor een budgetsysteempje en de winst in dagelijkse handelingen is beperkt. Daarom mag de RAID 0 opstelling niet veel meer kosten dan de 256gb opstelling.

Daarmee sluit je eigenlijk direct het gebruik van de betere SSD's in een RAID 0 opstelling uit; een 120gb Evo 850 is 67 euro en 256gb is 90 euro. Daarmee zou de RAID 0 opstelling 44 euro duurder zijn. En zelfs dan nog echt niet de dubbele performance geven in meerdere situaties. Want ik ben erachter dat <128gb toch wel een grote performance penalty geeft binnen dezelfde serie. Dan blijven de goedkopere SSD's over, dan kun je voor een 100-105 euro ofzo klaar zijn. Maar als ik kijk naar snelheden dan laten die al te wensen over tov de betere 128gb SSD's, laat staan tov de betere 256gb SSD's die ook sneller zijn omdat ze groter zijn (parallelism). Dus eigenlijk kom ik tot de conclusie dat de performance winst in veel/meeste gevallen beperkt tot niet aanwezig is in het geval van 2x budget 128gb SSD in RAID 0 vs 1x 256GB van een goed merk. Volgens mij ga je zelfs in sommige situaties er op achteruit.

Tot nu toe is dit mijn conclusie maar ik vroeg mij af of ik wellicht nog iets over het hoofd zie waardoor mijn conclusies niet juist zijn?

[Hann1BaL]

Voor een budgetsysteem ga jij het performanceverschil niet merken.
Met een RAID 0 wordt je risico op failure meer dan 2x zo groot.

Ik zou daarom echt adviseren gewoon voor een 256/250GB SSD te gaan. Dat levert je echt meer op en er is geen verstandige reden om RAID 0 te kiezen met 2 kleinere SSDs imho.

Al sinds jaren zijn de SSDs zo snel dat het gewoon "snel!" is en de theoretische benchmark performance is eigenlijk minder relevant. Maximale read/write snelheid ook niet. Heb je een redelijke SSD, zie BBGs, dan zit je gewoon goed.

[ Voor 27% gewijzigd door Hann1BaL op 20-10-2015 11:03 ]

[JT]

Dat risico snap ik, wat er op m'n SSD zou staan en belangrijk is wordt constant gesynchroniseerd naar een NAS. Dus dat punt is op mij niet van toepassing. Je kunt inderdaad discussieren over het nut maar "gewoon omdat het kan" is voor mij ook een reden mits de extra kosten binnen de perken blijven Als ik een keer 20mpix foto's ga bewerken/opslaan enzovoort in Photoshop dan heb ik er wellicht nog baat bij. Alleen zet ik m'n vraagtekens bij of het daadwerkelijk sneller gaat zijn en volgens mij zeg jij dat ook in je post?

[Tortelli]

Snelheidswinst in de praktijk zul je amper merken. De nadelen zijn groter: dataverlies en geen trim functie (oudere controllers ondersteunen geen trim onder raid voor zover ik weet).

Daarnaast zijn grotere ssd's vooral qua write snelheid aanzienlijk sneller.

[JT]

Zoals genoemd is dataverlies voor mij niet zo een probleem vanwege doorlopende synchronisatie. TRIM werkt wel op de 6x serie (kwam ik tegen). Dat laatst eis voor mij echter zeer belangrijk in de zin van, ik ga niet meer betalen voor een lagere schrijfsnelheid

[naftebakje]

Een ssd van 256 GB heeft minder overhead (verpakking, controller, software, marketing,...) dan twee SSDs van 128GB, je zal dus meer waar krijgen voor hetzelfde geld als je een SSD neemt van 256GB.
Daarnaast is de aansturing van de geheugenchips intern in de SSD gelijkend op raid0, maar kan deze dit veel efficiënter doen dan een "algemene" raid controller, dus je zal meer snelheid halen met een SSD van 256GB met minder risico op failure.

Enige reden waarom je twee SSD's in raid0 zou willen nemen is "gewoon omdat het kan" of "om te patsen", dan neem je beter een RAID0 array van 256 USB sticks van 1 GB.

[P_Tingen]

Theoretisch zul je met 2x128 in raid misschien je doorvoer kunnen verhogen maar dat ga je niet redden op een normale Sata aansluiting, dan moet je al over naar een m2 formaat. En zelfs met je 20mpix foto's betwijfel ik het of je het gaat merken. Dan kun je wellicht beter de meerprijs van 2x128 ssd's in extra geheugen steken.

JT schreef op dinsdag 20 oktober 2015 @ 12:05:
Zoals genoemd is dataverlies voor mij niet zo een probleem vanwege doorlopende synchronisatie.

Dataverlies misschien niet, maar harddisk failure komt al-tijd ongelegen dus wat dacht je van goed-humeur-verlies?

[ Voor 32% gewijzigd door P_Tingen op 20-10-2015 12:17 ]

[Point.Flare]

P_Tingen schreef op dinsdag 20 oktober 2015 @ 12:16:
Theoretisch zul je met 2x128 in raid misschien je doorvoer kunnen verhogen maar dat ga je niet redden op een normale Sata aansluiting, dan moet je al over naar een m2 formaat. En zelfs met je 20mpix foto's betwijfel ik het of je het gaat merken. Dan kun je wellicht beter de meerprijs van 2x128 ssd's in extra geheugen steken.


[...]

Dataverlies misschien niet, maar harddisk failure komt al-tijd ongelegen dus wat dacht je van goed-humeur-verlies?

Tenzij hij natuurlijk al 16 gig in zijn PC heeft (wat deze tijd ongeveer de norm is). Wanneer je in dat geval meer geheugen koopt, dan voegt het weinig toe. Tenzij je besluit tot een RAMDISK.

**Neemt niet weg dat twee kleinere SSD's in RAID weinig toevoegen. Ik heb twee oudere SSD's in RAID0 gedraaid tegenover twee WD Black Caviar in RAID0. Buiten de acces times om, haalde ik dezelfde overdrachtssnelheden..**

[TIGER79]

mijn ervaring is dat ssd's in raid een mooie sprong doen in lees-snelheid maar ook achteruit gaan op schrijf-snelheid tov een enkele....
Of tenminste dat is zo in mijn laptop, heb net geen gigabyte per seconde leessnelheid maar maar iets van 200 mb/s aan schrijfsnelheid...

[Croga]

Realiseer je vooral goed dat RAID0 weliswaar een hogere sequentiele doorvoersnelheid kent, maar ook een lagere random access tijd.

Vraag je dus even af wat je normale gebruik is:
- Alleen hele grote bestanden: RAID0 heeft een voordeel
- Veel kleine bestanden: RAID0 gaat het langzamer maken!

Nagenoeg alle gebruik behalve foto/video bewerking valt in die tweede categorie en gaat je dus met RAID0 alleen maar vertraging bieden. In real life situaties is dit dus niet zinvol.

Realiseer je daarnaast dat SSDs intern al het RAID0 principe doorvoeren door parallelle aansturing van de flash chips. Hierdoor zijn grotere SSDs over het algemeen al sneller dan kleinere. Het enige wat RAID0 je dan nog oplevert is de theoretische versnelling van het gebruik van meerdere SATA verbindingen.

Al met al is er geen enkele reden om RAID0 te gebruiken voor SSDs tenzij je SSDs van 500GB hebt en 1 volume wilt (en zelfs dan is JBOD waarschijnlijk beter).

[dcm360]

Croga schreef op dinsdag 20 oktober 2015 @ 12:35:
Realiseer je vooral goed dat RAID0 weliswaar een hogere sequentiele doorvoersnelheid kent, maar ook een lagere random access tijd.

Een hogere random access tijd dus (klopt wel met de rest van jouw verhaal)

[Croga]

dcm360 schreef op dinsdag 20 oktober 2015 @ 12:40:
Een hogere random access tijd dus (klopt wel met de rest van jouw verhaal)

You are absolrutery light!

[JT]

Dat is een hoop goede info...mijn beslissing was al 95% zeker, nu 100% Tnx allen.

[Anoniem: 15758]

Croga schreef op dinsdag 20 oktober 2015 @ 12:35:
Realiseer je vooral goed dat RAID0 weliswaar een hogere sequentiele doorvoersnelheid kent, maar ook een lagere hogere random access tijd.

Vraag je dus even af wat je normale gebruik is:
- Alleen hele grote bestanden: RAID0 heeft een voordeel
- Veel kleine bestanden: RAID0 gaat het langzamer maken!

Sorry maar dit is absoluut onzin!

Het is een vastgeroeste mythe dat RAID0 alleen sequential I/O zou verhogen. Hetzelfde is ook het geval met Random IOps. Daarom doen SSDs het zo goed; zij kunnen door de interne interleaving (RAID0) hun IOps meer dan vertienvoudigen. Zonder het gebruik van 'RAID0' oftewel interleaving, zou een SSD met hogere queue depth dezelfde score halen als met enkele queue depth; dus 20MB/s voor lezen. Echter is 250MB/s met multiqueue prima mogelijk, en dat komt dus door RAID0.

Hetzelfde is waar als je RAID0 op host-niveau uitvoert. Het enige dat RAID0 niet kan versnellen is blocking random reads. Daarom doen alle SSDs ongeveer hetzelfde: 20MB/s. Dit is volledig latency gebonden. Alleen SLC voegt dus wat toe en dat zie je met Samsung EVO en MX200 modellen terug in de score. Maar afgezien daarvan doen alle SSDs het op dit punt gelijk. Alle andere performanceaspecten kan RAID0 wel versnellen.

Het is te wijten aan ultra-slechte reviews/benchmarks van Anandtech en Storagereview, die vroeger riepen dat RAID0 geen plaats had op de desktop. Dit hadden zij echter gedaan met een PCI FakeRAID kaartje met ultrabrakke Windows-only RAID drivers met een lage stripesize en dan ook nog eens een misalignment (31.5K offset). Dat is dus de slechts mogelijke configuratie die je kunt hebben en dat zorgt er inderdaad voor dat je alleen voordeel haalt op sequential I/O en ook dat je latency per I/O hoger wordt omdat je meerdere disks aanspreekt voor één I/O request. Dus de langzaamste disk bepaalt dan het resultaat. Bij een goed geconfigureerde RAID0 is de absolute latency vrijwel gelijk - alleen de RAID driver voegt een miniscule latency toe - maar dat is echt maar heel weinig.

De gemiddelde latency halveert bij gebruik van RAID0, omdat je dan rekent: 1/IOps. Of anders gezegd: als je twee keer zoveel IOps doet, is de gemiddelde latency ook maar de helft.

Dat JBOD beter zou zijn kan ik naar het rijk der fabelen verwijzen. RAID0 is enorm krachtig en voor SSDs zeer goed bruikbaar. Het punt is alleen dat een enkele SSD al heel snel is, een twee keer sneller opslagapparaat voegt nog maar weinig toe. The point of deminishing returns heet dat met een deftig woord.

[JT]

Bedankt voor het duidelijke betoog.

Anoniem: 15758 schreef op dinsdag 20 oktober 2015 @ 14:00:
[...]


[...]

Het punt is alleen dat een enkele SSD al heel snel is, een twee keer sneller opslagapparaat voegt nog maar weinig toe. The point of deminishing returns heet dat met een deftig woord.

Daarom wil ik dus niet 1,5 keer zo duur uit zijn. Alleen dan kom ik bij budget SSD's uit. Wat is jouw kijk daarop? 2x128gb budget SSD of 1 keer goede 256gb SSD?

[ Voor 4% gewijzigd door JT op 20-10-2015 14:07 ]

[Croga]

Anoniem: 15758 schreef op dinsdag 20 oktober 2015 @ 14:00:Sorry maar dit is absoluut onzin!

Laat ik even voorop stellen dat jouw kennis ver voorbij die van mij gaat.

Bij een goed geconfigureerde RAID0 is de absolute latency vrijwel gelijk - alleen de RAID driver voegt een miniscule latency toe - maar dat is echt maar heel weinig.

Hier stel je twee heel belangrijke dingen:
- Goed geconfigureerde RAID0. Ergo; alleen als je precies weet waar je mee bezig bent en er tijd in steekt. Hoe zit het met "Ik vrot 2 schijven in m'n systeem en klik \"RAID0\" aan"? Ofwel: Als ik nou geen moeite stop in de configuratie, gaat het dan ook nog op?
- Er is zowieso een latency hit.

De gemiddelde latency halveert bij gebruik van RAID0, omdat je dan rekent: 1/IOps. Of anders gezegd: als je twee keer zoveel IOps doet, is de gemiddelde latency ook maar de helft.

Hiermee halveert dus niet de latency van een request. Als ik een bestand wil ophalen, of zelfs 10 bestanden wil ophalen, is m'n latency nogsteeds gewoon de latency van de langzaamste schijf + een beetje overhead. Of snap ik het nou niet?

Dat JBOD beter zou zijn kan ik naar het rijk der fabelen verwijzen. RAID0 is enorm krachtig en voor SSDs zeer goed bruikbaar. Het punt is alleen dat een enkele SSD al heel snel is, een twee keer sneller opslagapparaat voegt nog maar weinig toe. The point of deminishing returns heet dat met een deftig woord.

mwah, dan zou M.2 en NVME dus helemaal niet interessant zijn.....

[Anoniem: 15758]

JT schreef op dinsdag 20 oktober 2015 @ 14:06:
Daarom wil ik dus niet 1,5 keer zo duur uit zijn. Alleen dan kom ik bij budget SSD's uit. Wat is jouw kijk daarop? 2x128gb budget SSD of 1 keer goede 256gb SSD?

Ik ben juist wel voorstander van RAID0 met SSDs, heb ik zelf ook. Maar, begrijp wel dat het vooral overkill is - je doet het omdat het kan, en omdat het niets extra kost.

Tenminste, als je SSDs vanaf een bepaalde grootte neemt. Want de kleinste modellen zijn wel duurder per GB. Maar zou je 2x 250GB versus 1x 500GB vergelijken, kom je op bijna hetzelfde bedrag uit. Dan vind ik het zelf juist wel leuk om ze in RAID0 te draaien. Vooral met SATA/600 SSDs kun je daardoor boven de SATA/600 cap uitkomen en dat kan soms nog wel iets uitmaken. Starten van Games bijvoorbeeld. Dat gezegd, veel desktop dingen leunen op blocking random reads en dat gaat dus met 20MB/s en valt ook niet verder te versnellen met RAID0. Dus het belangrijkste performanceaspect doe je niets aan. Maar 20MB/s aan 4K I/O is nog steeds lekker snel. De rest kun je wel versnellen.

Bovendien, als je Intel onboard RAID gebruikt kun je ook Volume write-back cache inschakelen. Dit is een grotere write-back wat opzichzelf al - dus afgezien van de disk performance - de real-life performance verbetert. Dit omdat writes tussendoor 'verdwijnen' en min of meer tegen RAM snelheid gaan. Net een soort RAPID dus, maar ik heb veel meer vertrouwen in de software van Intel.

Ten slotte wil ik wel waarschuwen voor een risico met RAID-configuraties en Samsung SSDs. Deze ondersteunen namelijk journal rollback omdat ze geen hardwarematige bescherming hebben (power-safe capacitors). Dit werkt prima verder voor een standalone SSD voor de desktop, maar voor geavanceerde opslag kan dit problemen opleveren. Bedenk je wat er gebeurt als de ene SSD een rollback doet maar de andere niet. Dan heb je een RAID0 waarbij snippertjes van een iets oudere datum zijn dan de andere in-elkaar-gevlochten helft. Dat gaat je filesystem weer corrigeren ('this disk needs to be checked') en dat gaat vliegensvlug, maar je kunt hierdoor toch lichte corruptie krijgen. Bedenk hierbij dat bijvoorbeeld Windows updates niet helemaal goed/volledig worden uitgevoerd omdat het filesystem dingen weer terugdraait/corrigeert. Je kunt hier dus problemen door krijgen, al is die kans wel beperkt omdat in veel gevallen de schade enorm meevalt. Crucial MX200 heeft mijn voorkeur boven Samsung. Ook leuk is dat sommige modellen DWA hebben waardoor je de performance van een SLC SSD krijgt als je maar de helft benut. Dit geldt voor het 250GB SATA model en de 250/500GB M.2 modellen.

[ Voor 5% gewijzigd door Anoniem: 15758 op 20-10-2015 14:15 ]

[JT]

Ja precies, 2x128 vs 1x256 van een van de tippers is 1,5 keer zo duur. Dus dan zou ik terugvallen op budget SSD's. Wat zou jouw keuze zijn in deze?

En als ik zoek op DWA dan kom ik alleen Micron/Crucial tegen, wat mij tot de conclusie doet komen dat als ik dat wil ik een Crucial MX200 moet nemen?

[Anoniem: 15758]

Croga schreef op dinsdag 20 oktober 2015 @ 14:13:
Hier stel je twee heel belangrijke dingen:
- Goed geconfigureerde RAID0. Ergo; alleen als je precies weet waar je mee bezig bent en er tijd in steekt. Hoe zit het met "Ik vrot 2 schijven in m'n systeem en klik \"RAID0\" aan"? Ofwel: Als ik nou geen moeite stop in de configuratie, gaat het dan ook nog op?

Vroeger gebruikten we Windows XP en zaten we met slechte partities. Windows XP deed alignment op cylinder-niveau en dan zit je op 63 sectoren. En nee, niet 0-63 maar 0-62 dus 63 sectoren. Daarom kom je ook aan de 31.5KiB alignment. Want 63 * 512 bytes = 31.5K.

Dit is wat je ziet met AS SSD als je een 'XP' partitie hebt: 31.5K - BAD.

Tegenwoordig is dit geen issue meer omdat Vista (ik dacht Vista SP1+) en dus ook Win7/8/10 gewoon goed alignen op 2048 sectoren dus 1MiB. Dat is goed voor alle RAID0, maar niet altijd voor RAID5 en RAID6.

Verder is er de stripesize; die wordt vaak op 128KiB gezet. Hoger is beter voor random I/O, lager is beter voor sequential I/O. Ook dit wordt vaak precies verkeerd dus andersom uitgelegd. Veel mensen denken dat een grotere stripesize juist goed is voor sequential I/O. Bij SSDs geldt het overigens net iets anders want SSDs zijn vooral transfer capped en niet latency/seek capped zoals HDDs. Bij SSDs zou het zin kunnen hebben om de stripesize op 32K te zetten bijvoorbeeld. Dan zou een 64K read versneld worden omdat beide SSDs een deel uitvoeren.

Ten slotte gebruiken we nu geen brakke PCI kaartjes met slechte FakeRAID drivers en sowieso een PCI bottleneck. We gebruiken nu onboard RAID (ook FakeRAID) via de chipset en die heeft meer bandbreedte en veel lagere latency. Dus ook deze penalty vervalt bij moderne systemen.

Kortom, maak je 'gewoon' een RAID0 aan op je Intel onboard RAID dan kun je niet zoveel fout doen. Alleen cloningprogramma's gebruiken nog wel eens foute 31.5K alignment - daar moet je wel mee oppassen. Maar verder kun je het eigenlijk niet fout doen, zolang je maar bij Intel blijft - of je werkt met software RAID onder Linux/BSD die de beste RAID implementaties hebben.

- Er is zowieso een latency hit.

RAID0 kost echt heel weinig CPU power, dus dat mag eigenlijk geen naam hebben. Je maakt het ook ruimschoots weer goed met de gewonnen performance op andere gebieden (IOps/throughput).

Daarnaast: latency is vaak niet belangrijk. Voor writes is latency niet belangrijk behalve voor (blocking) sync writes. En ook voor mutliqueue random reads is IOps belangrijker dan absolute latency.

Dit kun je ook vergelijken met technieken zoals HyperThreading. Dit kan ook de 'latency' verhogen - dus de tijd dat het duurt om een instructie te verwerken. Maar omdat je meer instructies per seconde doet ('IOps') is het geheel sneller. Voor applicaties die crunching doen en toch altijd genoeg werk kunnen aanleveren, is de latency totaal onbelangrijk alleen de transaction rate dus 'IOps'. Voor andere zaken is latency juist wel belangrijk, en kan HyperThreading juist iets remmend werken op de prestaties. Dit principe geldt ook voor I/O. Met name blocking random reads ('4K') is latency vrijwel de enige relevante factor. De latency valt direct uit te rekenen naar IOps en Throughput (MB/s).

Hiermee halveert dus niet de latency van een request. Als ik een bestand wil ophalen, of zelfs 10 bestanden wil ophalen, is m'n latency nogsteeds gewoon de latency van de langzaamste schijf + een beetje overhead. Of snap ik het nou niet?

De absolute latency blijft gelijk (of iets nét ietsje hoger) - dat klopt. De gemiddelde latency halveert echter wel.

Denk aan een snelweg. Je hebt 10 auto's rijden over een stuk weg. Ze doen er allemaal 100 minuten over om hun bestemming te bereiken. De absolute latency is hier 100 minuten. De gemiddelde latnecy is hier 10 minuten omdat gemiddeld elke 10 minuten een auto op de bestemming aankomt.

Gemiddelde latency is ook veel makkelijker uit te rekenen. Ik gebruik deze formules:

Throughput = IOps * Request Size
IOps = Throughput / Request Size
Request size = Throughput / IOps
Latency(absolute) = Queue depth / IOps (alleen geldig als alle I/O er even lang over doen)
Latency(average) = 1 / IOps

Uiteindelijk kun je alle I/O performance dus omrekenen: throughput, IOps of latency.

mwah, dan zou M.2 en NVME dus helemaal niet interessant zijn.....

M.2 is niet zo heel interessant nee, kom je alleen boven de SATA/600 cap uit. Dat kun je prima met RAID0 van meerdere SATA/600 SSDs doen.

NVMe is wel interessant omdat de latency verlaagt op software gebied. Dit kan de blocking 4K reads verder versnellen - iets wat met RAID0 niet lukt. Alleen SLC technieken als EVO (Samsung) en DWA (Crucial) kunnen dit. Dus met deze techniek + NVMe heb je ongeveer het beste wat je kunt bereiken met NAND opslag - alleen een fundamenteel andere techniek zoals PCM (Phase-Change Memory) zou dit performancegebied nog verder kunnen verbeteren.

[ Voor 6% gewijzigd door Anoniem: 15758 op 20-10-2015 14:41 ]

[Anoniem: 15758]

Even in een aparte post, vanwege de overzichtelijkheid:

JT schreef op dinsdag 20 oktober 2015 @ 14:18:
Ja precies, 2x128 vs 1x256 van een van de tippers is 1,5 keer zo duur. Dus dan zou ik terugvallen op budget SSD's. Wat zou jouw keuze zijn in deze?

Als het je om het geld te doen is: koop een enkele 250GB SSD.

Als het je om de grootte te doen is: overweeg 2x Crucial MX200 250GB in RAID0 en gebruik maar de helft zodat je de SSD als SLC SSD kunt gebruiken. Dit doe je door simpelweg een partitie te maken zodat beide SSDs maximaal voor de helft gevuld worden. 45% is nog beter.

En als ik zoek op DWA dan kom ik alleen Micron/Crucial tegen, wat mij tot de conclusie doet komen dat als ik dat wil ik een Crucial MX200 moet nemen?

DWA is een techniek van Crucial MX200, in feite een verbeterde versie van wat Samsung met de EVO modellen doet: een SLC cache. Alleen is die bij Samsung statisch waardoor alleen recent geschreven data als SLC weg gaat, dit is puur om hoge scores te kunnen claimen zodat Samsung goed kan verkopen.

Maar bij Crucial werkt het ook voor lange reeds beschreven data, die blijft als SLC want DWA is dynamisch. De data wordt pas omgezet van SLC naar MLC als de SSD ruimte tekort krijgt. Zorg je dat dit nooit gebeurt - door partities aan te maken - dan heb je dus voor alle opgeslagen data de performance van een SLC SSD. Dat is een enorm gave feature!

[JT]

Als het m'n hoofdcomputer werd dan had ik dan 2x250 gedaan Voor nu hou ik het dan bij 1x 250gb MX200. Dank voor je input.

[Anoniem: 100482]

Anoniem: 15758 schreef op dinsdag 20 oktober 2015 @ 14:00:

Daarom doen alle SSDs ongeveer hetzelfde: 20MB/s. Dit is volledig latency gebonden. Alleen SLC voegt dus wat toe en dat zie je met Samsung EVO en MX200 modellen terug in de score. Maar afgezien daarvan doen alle SSDs het op dit punt gelijk.

Dat is ook zo...

Daarom ook dat een Crucial M500 al 29 neerzet in random 4K read in CrystalDiskMark,
en een Samsung 850 Pro zelfs over de 40 doet.
Het dubbele dus...

[Wim-Bart]

Anoniem: 15758 schreef op dinsdag 20 oktober 2015 @ 14:14:
[...]
Ten slotte wil ik wel waarschuwen voor een risico met RAID-configuraties en Samsung SSDs. Deze ondersteunen namelijk journal rollback omdat ze geen hardwarematige bescherming hebben (power-safe capacitors). Dit werkt prima verder voor een standalone SSD voor de desktop, maar voor geavanceerde opslag kan dit problemen opleveren. Bedenk je wat er gebeurt als de ene SSD een rollback doet maar de andere niet. Dan heb je een RAID0 waarbij snippertjes van een iets oudere datum zijn dan de andere in-elkaar-gevlochten helft. Dat gaat je filesystem weer corrigeren ('this disk needs to be checked') en dat gaat vliegensvlug, maar je kunt hierdoor toch lichte corruptie krijgen. Bedenk hierbij dat bijvoorbeeld Windows updates niet helemaal goed/volledig worden uitgevoerd omdat het filesystem dingen weer terugdraait/corrigeert. Je kunt hier dus problemen door krijgen, al is die kans wel beperkt omdat in veel gevallen de schade enorm meevalt. Crucial MX200 heeft mijn voorkeur boven Samsung. Ook leuk is dat sommige modellen DWA hebben waardoor je de performance van een SLC SSD krijgt als je maar de helft benut. Dit geldt voor het 250GB SATA model en de 250/500GB M.2 modellen.

Dit is wel een interessante, maar zelfs met caps heb je een uitdaging. Want als de ene disk wel genoeg tijd heeft om via caps de data weg te schrijven maar de raid controller deel twee niet naar de andere SSD heeft geschreven? Persoonlijk heb ik liever dat of beide disks zeker schrijven of alle twee failen. Dus Raid zonder BBU is altijd een uitdaging. Daarnaast zit je nog met de stripe size. Wat is de kans dat een write hoger dan de stipe plaats vindt of volledig is tijdens uitval.

Daarom, welke RAID oplossing je ook kiest, op het moment dat een Filesysteem is gedistribueerd over meerdere media (SSD, HDD) is er geen andere oplossing dan een UPS. Software kan goed zijn, maar zonder power maakt iedere beveiliging niks meer uit. Heb al te veel filesystemen kapot zien gaan door power loss omdat er geen goede bescherming was.

Hardware RAID: Altijd een BBU of een UPS
Software RAID: Altijd een UPS
Geen BBU of UPS = Geen RAID.

Net zoals ECC in een Software based RAID systeem een must is.

[ Voor 12% gewijzigd door Wim-Bart op 20-10-2015 15:29 ]

[Anoniem: 15758]

Wim-Bart schreef op dinsdag 20 oktober 2015 @ 15:20:
[...]


Dit is wel een interessante, maar zelfs met caps heb je een uitdaging. Want als de ene disk wel genoeg tijd heeft om via caps de data weg te schrijven maar de raid controller deel twee niet naar de andere SSD heeft geschreven?

Dat is iets wat alle 2e generatie filesystems al hebben opgelost met sync writes / journalling / write barriers / soft-updates. Kortom het scheiden van data en metadata. Het verlies van recente writes kunnen 2e generatie filesystems dus prima aan. Dat probleem heb je ook met hardeschijven met DRAM chip.

Vroeger, in het Win95/98/ME tijdperk, moest tijdens het opstarten vaak 'scandisk' draaien om het filesystem weer consistent te maken. Bestanden verdwenen daarbij soms in de Lost&Found directory (found.000) omdat het filesystem eigen deels corrupt/inconsistent is geworden omdat recente writes zijn verloren.

1e generatie filesystems zijn FAT16/32, Ext2 en UFS
2e generatie filesystems zijn NTFS, Ext3/4, UFS2+SU (Soft Updates)
3e generatie filesystems zijn ZFS, Btrfs en ReFS (Checksums + ditto blocks)

2e generatie filesystems kunnen tegen verlies van recente writes, maar bieden verder geen enkele bescherming. 3e generatie filesystems bieden echte bescherming door middel van checksums en ditto blocks en kunnen corruptie detecteren en zijn in redundante configuraties immuun voor bad sectors.

Daarnaast zit je nog met de stripe size. Wat is de kans dat een write hoger dan de stipe plaats vindt of volledig is tijdens uitval.

Dat is dus geen issue - de metadata wordt later geupdate dan de data zelf. Bij een plotse onderbreking zal het filesystem worden teruggezet naar een eerdere staat die wel consistent is. De recente writes hebben dan simpelweg niet plaatsgevonden. Dit is een feature van 2e generatie filesystems. Dit is nodig voor alle opslag behalve hardeschijven met uitgeschakelde write cache, waardoor de hardeschijf met 1MB/s gaat schrijven ipv ~200MB/s.

Servers die vroeger nog UFS/Ext2 gebruikten, schakelden vaak de write cache uit vanwege dit probleem, met als gevolg veel lagere prestaties maar wel bescherming tegen filesystem corruptie wat je bij een server niet kunt hebben. 2e generatie filesystems kunnen DRAM write-back in hardeschijven veilig benutten zonder risico van inconsistentie/corruptie te lopen.

[Wim-Bart]

Anoniem: 15758 schreef op dinsdag 20 oktober 2015 @ 15:33:
[...]

Op zich heb je helemaal gelijk. Maar ik geloof meer in consistentie onder maximale performance condities. Vandaar dat ik bij een raid oplossing eigenlijk maar twee situaties wil tegenkomen:

1. Volledige update van de transactie
2. Een totaal gefaalde transactie

Gelukkig handelen moderne filesystemen dit netjes af, maar op het moment dat er een fout optreed is er maar 1 ding van belang, de metadata op de disk dient correct te zijn, daarom laat ik even in het midden of de oplossing van Samsung beter of slechter is dan de Cap oplossing. Waar ik van uit wil gaan is dat de interne boekhouding van een SSD correct is waarbij de daadwerkelijke data op de disk nu wel of niet correct is, want dit laatste is op te lossen door een rollback van het OS of een commit van het OS en tegenwoordig zit dat wel goed met veel filesystemen zoals ZFS, Btrfs en ReFS maar ook met NTFS. Liever dataverlies doordat een bestand niet is weggeschreven of gedeeltelijk is weggeschreven en filesysteem leesbaar/herstelbaar dan dat de hardware gewoon verkeerde "sectoren" gebruikt.