RAID5 op VIA VT8237R, array initialization status en caching

[Verwijderd]

Ik heb dit weekend mijn oude Raid0 (2x 500 GB samsung spinpoint t166's) vervangen door een 3-tal WD10EACS 1TB schijven, welke ik in raid5 wilde gaan draaien, vooral aangezien er grote hoeveelheden video op staan die ik niet wil backuppen (want teveel data), maar toch de moeite waard is om te blijven bewaren ook als er een keer een schijf zou crashen. Andere cruciale data (studie/werk etc) word uiteraard wel gebackupped, maar vandaar dus de keuze voor Raid5, ook al vermoed ik dat het erg traag gaat worden ivm de onboard chipset.

De chipset is een van het KT800pro (socket 939) met een via VT8237R onboard raidchip. Deze kan 0/1/01/10/5 aan.

Ik heb meteen van de gelegenheid gebruik gemaakt om de via chipset en raid drivers te updaten naar de laatste versie, 5.80, als ook de V-RAID raid software.

Nu zijn er een aantal dingen die ik merk:

het is traag (verassing!), maar ik ben erg benieuwd of de array niet nog aan het initializeren is. De V-RAID software gaf meteen na het creeeren van de RAID opstelling (waarbij de schijven gecleared mochten worden, niet de stripe0 data behouden dus) aan dat status "normal" was. Ik dacht dat dit nog wel een aantal uren zou duren op een 1.89TB volume. Ik ben overigens meteen begonnen met het terugsturen van data via het netwerk van Raid0->gbit->raid5 . Haal zo'n 9% performance over gigabit, waar het versturen van singledisk naar raid0 tot 40% gbit performance ging.
Weet er dus iemand hoe ik erachter kan komen of hij inderdaad nog aan het initializeren is en of ik me daar dus niet druk om hoef te maken? Sowieso lijkt het me een prettig idee om te weten wanneer hij weer klaar is met initialiseren in het geval van een eventuele schijfwissel.

Daarbij had ik gebruik gemaakt van de V-Raid (via-raid) software om de array te creeeren, maar kon ik geen chunksize opgeven. Wat schetst echter mijn verbazing als ik de v-raid eventlog bekijk:

RAID5 Array Created.
Array disks :
Stripe disk 0 (WDC WD10EACS-00D6B0 WD-WCAU42719197) on Controller 0, Channel 0, Master
Stripe disk 1 (WDC WD10EACS-00D6B0 WD-WCAU43043274) on Controller 0, Channel 1, Master
Stripe disk 2 (WDC WD10EACS-00D6B0 WD-WCAU44067790) on Controller 0, Channel 2, Master
Block size = 2048K

Block size 2048K? Dat zou 2mb per block zijn? Of juist 2K?


En dan last but not least: zodra ik op de raidarray in devicemanager, bij de policies tab "write caching" wil aanzetten krijg ik steeds een eventid34 : "the driver has disabled write caching for this volume". Dit terwijl dit vroeger met de oude drivers, notabene op een raid0 array, wel kon. Ik weet dat batterybackup/ups beter zou zijn, maar geloof wel dat dit vreselijk veel performance moet kosten...

[McKaamos]

Een onboard chipsetje is idd knap traag. Write Caching aanzetten zou misschien helpen, maar gezien je daar voor een BBU nodig hebt zal dat niet gaan.
BBU = Battery Backup Unit. Dat is geen UPS maar een batterij die je kan aansluiten op de RAID controller om het memory te behouden wanneer de stroom uitvalt. Gezien de controller geen UPS kan controleren zal hij dat dus niet zien als vorm van een BBU.

Verder, hoe groter de Block Size, hoe meer performance op langere transfers (b.v. een ISOtje kopieren). Als je veel kleine files hebt zal het trager worden met een grotere blocksize, maar als je een kleine blocksize neemt en grote transfers doet krijg je de maximale performance niet.
Vaak wordt gekozen voor ergens tussen 64K en 512K. 2048K is erg veel vziw.

Anyway, als je performance wil hebben, heb je een betere RAID ccontroller nodig.
Als je heel goedkoop sneller wil, kan je misschien een XFX Revo64 overwegen. Niet de snelste, en het is een PCI kaart dus maximale snelheid haal je nogsteeds niet, maar het is sowieso sneller als onboard.
En ja, het is RAID3 ipv RAID5, maar de theorie achter die twee is hetzelfde. Het enige verschil is dat RAID5 de parity data per block op een andere schijf zet en RAID3 dedicated 1 schijf gebruikt voor de parity data.

[Verwijderd]

Voor zover ik weet is het onmogelijk om op een onboard raid controller een backup battery te plaatsen. Maar het rare is dat het met de oude driverversie prima (edit: het enablen van cache in de policies tab) ging. Heb al behoorlijk wat andere mensen gevonden die hetzelfde probleem hadden maar kennelijk nog geen verbetering.

Blijft de vraag of mijn array nog aan het initializen is of niet. Kan ook geen melding van het starten (of compleet zijn) van de initializatie. En een gigantische blocksize als dat idd zo is.

Als ik weet of de performance zo bedroevend is door het initailizen, of dat het zo bagger blijft (ik draai ook 3 vm's vanaf dit array; kan me voorstellen dat hun swapfile writes ook niet handig zijn in dit geval) dan ga ik toch maar naar raid0 met dan de derde disk als backupdisk.. of raid01 met een 4e schijf erbij.

[ Voor 33% gewijzigd door Verwijderd op 03-08-2009 10:39 ]

[McKaamos]

Idd, onboard en een BBU gaat niet samen.
Sowieso is onboard te traag voor een fatsoenlijke RAID5.
Het kunnen gebruiken van Write Caching zonder BBU wordt gevaarlijk geacht en daarom zal het wss uitgezet zijn in de huidige driverversie.
Misschien kan je de driver aanpassen?

Anyway, ik denk niet dattie nog aan het initializen is. Vziw duurt dat niet zo gek lang bij een set lege disks. Maja, aan de andere kant, onboard is traag, dus misschien 48 uur wachten?