Performance en nut van Cache in raid configuraties

[CU2morO]

Na enige tijd gewerkt te hebben met een legio uiteenlopende raid controllers, harde schijven en raid configuraties kan ik echter nog steeds geen antwoord geven op de vraag, wat is het effect van cache op een hardeschijf in een raid configuratie.

De bedoeling van cache op een harde schijf is natuurlijk het snel aanleveren van bestanden / fragmenten die vaak opgevraagd worden. Bij de meeste gangbare schijven is dit 8 of 16MB.

Stel je hebt nu een grote raid array van laten we zeggen 10 schijven van 400-750GB oid / stuk. Deze schijven zet je op een raid controller die zélf ook al een flinke hoeveelheid cache heeft (meestal is dit 128 of 256MB op hardware controllers) en in een RAID 5 of 6 configuratie.

Is het nu niet zo, dat aangezien de data dusdanig verspreid is over de schijven, dat data veel minder vaak 2x wordt opgevraagd, en wanneer er uberhaupt data wordt opgevraagd, dat deze in het 'voorste' cache van de raid controller wordt gezet?

Laten we zeggen voor het gemak dat we 128MB cache op onze controller hebben, en 8 schijven met 16MB cache. Stel nu dat alle data perfect verdeeld over de schijven is, en wanneer er dan een bestand van 128MB ingeladen wordt, staat die in de cache van de schijven én van de raid controller.

Op deze manier ben ik dus van mening dat een dubbele cache (controller en schijven zelf) eigenlijk bijna nul performance winst boekt. Aangezien heel vaak dezelfde data zich zal bevinden in beide caches.

Zit ik er nu compleet naast of is dit een correcte manier om er tegenaan te kijken en zou het dus niet verstandig zijn om extra te betalen voor cache op de disk zelf? (in een configuratie van 10-16 schijven telt iedere euro die je bespaard op schijven 10-16x )

[Anoniem: 41852]

'Cache' in de hardeschijven dient primair als buffer voor write back cache in de schijven zelf. Zo kan zonder gebruik van NCQ er toch een redelijke hoeveelheid gegevens geschreven worden. Zonder ATA write cache (hetgeen je dus kunt in- of uitschakelen) heb je een veel lagere schrijfsnelheid maar wel een betrouwbare opslag.

Moderne schijven liegen namelijk als ze een I/O write request voltooid hebben. Ze geven direct aan dat de request voltooid is zodat ze een volgende request kunnen aannemen. Intern wordt de request in een wachtrij geplaatst in het volatile DRAM geheugen (ook wel buffercache genoemd). Mocht er een stroomstoring optreden, ben je alle requests kwijt in de buffercache van je hardeschijf. Schakel je ATA write cache uit dan ben je hooguit 1 schrijfopdracht kwijt, hetgeen journaling gemakkelijk kan opvangen.

[CU2morO]

Ah ok.

Dus als ik het goed begrijp, dient de cache hoofdzakelijk of enkel voor schrijf acties, en maakt het voor lezen niet uit? En het cache op de raid controller dient wél als cache voor vaak gebruikte bestanden / segmenten?

[Anoniem: 41852]

Het is ook voor leesacties ja, met name read-ahead. Schijf krijgt een leesactie voor een bepaalde sector, en leest alvast vooruit en zet die gegevens in de cache. Als dan zoals verwacht een aaneensluitend blok wordt opgevraagd kan deze direct uit de cache geserveerd worden. Zonder deze techniek kun je nooit de maximale doorvoersnelheid voor lezen bereiken (70-80MB/s bij moderne schijven).

Een controller doet min of meer hetzelfde, maar heeft natuurlijk veel meer buffercache ter beschikking, doorgaans iets van 256MB. Als je dan 100MB schrijft, gaat dat direct naar de buffer. Dan schrijf je dus op de maximale snelheid van de controller (bij Areca is dat 440MB/s). Ook al zijn de schijven zo traag als slakken. Enig probleem hierbij is veiligheid: als de stroom uitvalt gaan de gegevens in de buffer verloren. Dat is ook de reden dat sommigen de write buffer in de schijven zelf uitschakelen voor maximale betrouwbaarheid. Bij de controller kun je het opvangen door een BBU (Battery Backup Unit) te plaatsen die zorgt dat de gegevens in de onboard RAM niet verloren gaan.