RAID 10 en Write-back Cache

[Mentox]

Ik heb nu vier schijven van 320Gb in RAID 10 staan.

De snelheden zijn circa 150MB`s. Wanneer ik Write-back Cache aanzet is dit ongeveer 230MB`s.

Hoewel dit theoretische cijfers zijn voelt het systeem sneller aan met Write-back cache ingeschakeld. Ik gebruik RAID 10 om een snel en veilig systeem te hebben. Nu weet ik dat wanneer je bij RAID 0 Write-back Cache aanzet je om problemen vraagt.

De hardware die ik gebruik is het volgende:
4x Seagate Barracuda 7200.10 320GB 16MB S-ATA II
De RAID zit op een Intel ICH8R Controller

Mijn budget laat het helaas niet toe om een apparte RAID controller te kopen.

Hoe zit dit met RAID 10? Is er een risico? Als er een risico is hoe groot is dit dan? Wat raden jullie me aan?

[ Voor 33% gewijzigd door Mentox op 28-02-2007 23:10 . Reden: Vergeten te melden wat ik gebruik ]

[Microkid]

Een write back cache heeft altijd een risico. Mocht de spanning uitvallen dan is de informatie in de cache weg en verloren. Je zit dan meest waarschijnlijk met een corrupte disk.
Daarom dat professionele servers altijd een "battery backed write cache" gebruiken. De cache wordt hier gevoed door een accu. Mocht de spanning uitvallen, dan blijven de write opdrachten veilig in de cache staan, totdat het systeem weer online komt. Sommige consumenten RAID controllers bieden deze optie ook, zoals o.a. Areca ARC-1210, 3Ware 9650-SE, Promise EX4350.

[maratropa]

Waar stel je die write cache in?

Iig heeft de standaard write cache van windows voor non raid schijven wel een extra beveiliging. Als de driver opdracht van software krijgt om niet te cachen wordt er meteen write-through geschreven. De advanced performance mode cached alle writes, en is dus het linkst.

Maar dit geld vast niet op die ICH8R in raid...

[BalusC]

Dit kun je instellen via de BIOS, via de drivereigenschappen en/of via 3rd party tooltjes

Maar voor thuisgebruik zou ik er niet moeilijk over doen. Het risico op dataverlies geldt alleen voor de bestanden die op het moment worden weggeschreven en niet voor de bestanden die er al staan.

[Mentox]

Dus als de spanning eraf gaat of de PC loopt vast kan dat niet veel kwaad als er geen belangrijke bestanden werden gekopieerd?

En als het fout gaat raakt mijn gehele configuratie dan corrupt of enkel èèn schijf?

[ Voor 25% gewijzigd door Mentox op 01-03-2007 07:41 ]

[BalusC]

Nee, enkel het bestand dat op het moment wordt weggeschreven raakt corrupt.

[ Voor 33% gewijzigd door BalusC op 01-03-2007 08:15 ]

[Mentox]

Dus het risico is gering?

[vinnie1908]

Als jij het bestand dat je wegschrijft van essentiele waarde vind zal je flink balen, de kans dat dit het geval is zal niet heel groot zijn vermoed ik. Risico is dus gering

[Aike]

Mentox schreef op donderdag 01 maart 2007 @ 08:23:
Dus het risico is gering?

Ja, maar wel afhankelijk van je gebruik. Als jij je pc 's ochtends aanzet, en 's avonds weer uit verwacht ik geen problemen. Maar als je gaat OC'en en 4x per dag op reset drukt wel

[Dukey]

Ik draai al een tijdje een Promise EX8350 (zonder BBU) met 8x 500Gig's eraan in raid-6. Zowel de cache van de hardeschijven staat aan als de write-back functionaliteit van de controller. Ook is de pc (in al die tijd) wel eens uitgevallen en heb nog nooit te maken gehad met data corruptie, terwijl je dat wel zou verwachten volgens de theorie.

Nu heeft deze controller 'maar' 128mb werkgeheugen, wat natuurlijk wel eens de verklaring kan geven. Aangezien iemand met een Areca bijv en een 1gig reepje erop niet zo snel dat terug kan schrijven naar de schijven.

[ Voor 23% gewijzigd door Dukey op 01-03-2007 08:37 ]

[Mentox]

Ik heb niets overgeclockt omdat het risico dat er wat fout gaat niet opweegt tegen de extra prestaties.

Een E6600 met 2GB geheugen is snel genoeg en met RAID 10 inclusief Write-back Cache is het helemaal feest.

Bedankt voor de hulp.

[BalusC]

Mentox schreef op donderdag 01 maart 2007 @ 08:23:
Dus het risico is gering?

Dit kun je zelf incalculeren. Gewoon een stabiel systeem opzetten, dan is er niks aan het handje.

[maratropa]

Nouja dan kan de stroom nog steeds uitvallen natuurlijk.

Dukey schreef op donderdag 01 maart 2007 @ 08:35:
Ik draai al een tijdje een Promise EX8350 (zonder BBU) met 8x 500Gig's eraan in raid-6. Zowel de cache van de hardeschijven staat aan als de write-back functionaliteit van de controller. Ook is de pc (in al die tijd) wel eens uitgevallen en heb nog nooit te maken gehad met data corruptie, terwijl je dat wel zou verwachten volgens de theorie.

Nu heeft deze controller 'maar' 128mb werkgeheugen, wat natuurlijk wel eens de verklaring kan geven. Aangezien iemand met een Areca bijv en een 1gig reepje erop niet zo snel dat terug kan schrijven naar de schijven.

Controllers flushen ook om de zo veel tijd automatisch , dus het is niet zo dat er altijd data in de cache zit.

[Verwijderd]

Mentox schreef op woensdag 28 februari 2007 @ 22:07:
De snelheden zijn circa 150MB`s. Wanneer ik Write-back Cache aanzet is dit ongeveer 230MB`s.

Dit geloof ik eigenlijk niet zo. Welke transfer size heb je gebruikt? Je dient minimaal 8x de grootte van je RAM te gebruiken. Heb je 1GB aan RAM dan moet je dus minimaal 8GB aan data kopieren om je RAM geen overmatige rol te laten spelen. Het is bekend dat Intel ICH drivers een deel van je RAM als buffer gebruiken, dus bij een kleine transfersize krijg je dan onrealistisch hoge resultaten.

Wat wel zo is, is dat je writes met write back kunt uitstellen en dus efficienter kunt indelen. Zo kun je voorkomen dat je hardeschijf over de disk heen en weer gaat seeken en snel schakelt tussen lezen en schrijven. Een intelligent storage subsystem kan de I/O performance drastisch verbeteren!

Microkid schreef op woensdag 28 februari 2007 @ 22:23:
Een write back cache heeft altijd een risico. Mocht de spanning uitvallen dan is de informatie in de cache weg en verloren. Je zit dan meest waarschijnlijk met een corrupte disk.

Dat is niet per definitie waar. In combinatie met journaling en BIO FLUSHes is de kans op corruptie volledig uitgesloten, op welk moment de computer ook afslaat/reset/uitvalt.

Dat werkt zo: bij schrijfacties wordt alles eerst naar de journal (logboek) geschreven. Is een journal 'vol', dan wordt de journal afgesloten en naar de echte (definitieve) locatie geschreven op de disk. Het idee hierachter is, dat wanneer een stroomstoring/crash/reset zich voordoet het filesystem de laatste writes terug kan draaien ("rollback"). Het is dan alsof de writes nooit hebben plaatsgevonden.

Het probleem met buffercaches is dat, zowel de writes naar het journal als de writes van journal naar definitieve locatie in de buffer kunnen zitten; dan verliest de journal zijn beschermende werking omdat bij een crash zowel de journal als de data weg is. Erger nog: intelligente controllers/drivers kunnen I/O asynchroon uitvoeren waardoor een write-request nummer 15 eerst uitgevoerd wordt en daarna pas nummer 3, dus niet in synchrone volgorde. In deze situatie heb je inderdaad te maken met corruptie hetgeen een filesystem flink kan verwoesten.

De oplossing zijn BIO FLUSHes; een BIO FLUSH commando wordt gegeven door het filesystem aan de onderliggende storage layer, zoals een hardeschijf, hardware RAID controller of software RAID driver. Deze zal dan eerst alle informatie in de buffer wegschrijven naar disk, voordat nieuwe I/O request geaccepteerd worden. Dit flush-commando wordt uitgevoerd vlak na het voltooien van een journal, zodat de journal intact is weggeschreven en daarna het 'uitvoeren' van de journal kan beginnen, dus het wegschrijven naar de definitie locatie. Als alle storage layers flushes ondersteunen is er zelfs met write-back cache geen enkel risico op corruptie.

Helaas is het niet zo dat elke driver / RAID kaart / Operating System deze flushes ondersteunt. Als dat niet het geval is, loop je dus wel degelijk risico met write-back cache; en eigenlijk altijd omdat de harddisks ook een buffer hebben en als een van de layers geen flush ondersteunt komt dat dus ook niet door bij de harddisks.