Cachepolicy's voor de RAID-controller in TTY-logboek analyseren

TTY-logboeken (het RAID controller-logboek) bevat verwijzingen naar lees-, schrijf- en cachepolicy's die zijn toegewezen aan virtuele schijven.  Deze policy's kunnen de prestaties van virtuele schijven beïnvloeden en kunnen bij onjuist gebruik het risico van dataverlies in geval van een stroomstoring verhogen. 
 

Lees-policy's: 

• Geen read-ahead – de read-ahead cachepolicy niet gebruiken.
• Read-ahead – sequentiële schijfsectoren vóór de alsdan gelezen sector worden in cache opgeslagen.  Deze policy kan prestaties optimaliseren als data sequentieel worden opgeslagen.  Dit biedt meestal geen voordelen voor willekeurige leesbewerkingen.  (Handig voor toegang tot grotere en/of sequentieel opgeslagen bestanden)
• Adaptive Read-Ahead – Gebruikt alleen read-ahead caching als de vorige twee leesaanvragen toegang hebben verkregen tot sequentiële schijfsectoren.  Als dit niet het geval is, wordt geen read-ahead-policy gebruikt.

 
Schrijfpolicy's: 

• Write-Through (WT) – Een schrijfbewerking is alleen voltooid als de doelschijf meldt dat de schrijfbewerking is voltooid.
• Write-Back (WB) – Een schrijfbewerking is voltooid als de data zich in de cache van de controller bevinden, ook als de data niet zijn geschreven naar de bestemmingsschijf. 
  • Deze policy heeft een verhoogd risico van dataverlies, omdat alle niet op een schijf opgeslagen data verloren kunnen gaan als de voeding van het systeem uitvalt.  Dit risico kan mogelijk worden verlaagd door een cache met back-up-batterij te gebruiken.
  • WB-policy wordt weer WT als de batterijvoeding onvoldoende is om de data in de cache te houden
• Force Write-Back – Schrijfpolicy blijft Write-Back ongeacht de status van de batterij. 

 
Andere policy's: 

• Access Policy –
  • Read/Write – Staat lezen en schrijven naar het apparaat toe
  • Read Only – Staat alleen lezen naar het apparaat toe, geen schrijfbewerking toegestaan
    • SSD-schijven hebben beperkte schrijfcapaciteit.  Als het maximum aantal schrijfbewerkingen is bereikt, verandert de Access Policy in Read Only en kunnen geen schrijfbewerkingen meer worden uitgevoerd
  • Blocked – Er zijn geen lees- of schrijfbewerkingen toegestaan
• Disk Cache Policy – Staat, indien ingeschakeld, schrijfbewerkingen naar de cache van de schijf toe, vóór het medium
  • Bij virtuele schijven met SATA-schijven, is deze policy standaard ingeschakeld
  • Bij virtuele schijven met SAS-schijven, is deze policy standaard uitgeschakeld
  • Bij driver-RAID-controllers, zoals de SAS 6/iR en de H200, is deze policy alleen beschikbaar NADAT de virtuele schijf is gemaakt.

Veel aspecten van servertechnologie gebruiken andere nummeringsystemen dan het decimale stelsel (Base 10), zoals het binaire (Base 2) en hexadecimale (Base 16).  Conversie tussen nummeringssystemen is vaak nodig om de betekenis van specifieke waarden volledig te begrijpen.  

Een reeks van 4 bits in binair wordt vaak voorgesteld door een enkele waarde in hexadecimaal.  Hexadecimale waarden worden vaak gebruikt om veel grotere waarden in binair voor te stellen.  Conversie van een hexadecimale waarde van twee cijfers naar binair geeft 8 bits totaal, 4 bits per hexadecimale waarde.  Bij conversie van het hexadecimale getal 0d naar binair is de eerste hexadecimale waarde 0 gelijk aan 0000 in binair, en de tweede hexadecimale waarde d gelijk aan 1101 in binair.  Tezamen zijn de hexadecimale waarden 0d gelijk aan 0000 1101 in binair.  4 bits in binair wordt een 'nibble' genoemd, 8-bits is een "byte". 

0000 = 0            0100 = 4            1000 = 8            1100 = c

0001 = 1            0101 = 5            1001 = 9            1101 = d

0010 = 2            0110 = 6            1010 = a            1110 = e

0011 = 3            0111 = 7            1011 = b            1111 = f

Afbeelding 1:  Binaire naar hexadecimale conversie 
 

Dit is belangrijk omdat binaire waarden vaak als een bitmasker worden gebruikt voor verschillende instellingen en configuraties.  In bijvoorbeeld netwerken is het subnetmasker een reeks bits die wordt gebruikt om te bepalen hoeveel beschikbare netwerken er zijn en hoeveel hosts per netwerk kunnen worden geconfigureerd. 

Voor RAID-cachepolicy's is de bitmaskerdefinitie als volgt:

• dcp = standaardcachepolicy en ccp = huidige cachepolicy
  • x01 = write-back 
  • x04 = read-ahead
  • x08 = Adaptive Read Ahead
  • x10 = schrijfcache OK bij slechte BBU (Force Write Back)
  • x20 = schrijfcache toegestaan
  • x40 = leescache toegestaan

• ap - access policy (toegangspolicy)
  • 0 = lezen / schrijven
  • 2 = alleen lezen
  • 3 = geblokkeerd

• dc - disk cache policy (schijfcachepolicy)
  • 0 = ongewijzigd, gebruik schijfstandaard = (SAS uitschakelen, SATA inschakelen)
  • 1 = schijfschrijfcache inschakelen
  • 2 = schijfschrijfcache uitschakelen

x01 duidt de bytewaarde 1 aan in het tweede binaire datawoord – 0000 0001 – het gemarkeerde cijfer

x04 duidt de bytewaarde 4 aan in het tweede binaire datawoord – 0000 0100 – het gemarkeerde cijfer

x08 duidt de bytewaarde 8 aan in het tweede binaire datawoord – 0000 1000 – het gemarkeerde cijfer

x10 duidt de bytewaarde 1 aan in het eerste binaire datawoord – 0001 0000 – het gemarkeerde cijfer

x20 duidt de bytewaarde 2 aan in het eerste binaire datawoord – 0010 0000 – het gemarkeerde cijfer

x40 duidt de bytewaarde 4 aan in het eerste binaire datawoord – 0100 0000 – het gemarkeerde cijfer 

Bij analyse van de uitvoer van de controllerlogboeken kunnen specifieke cache-instellingen worden bepaald door de afzonderlijke chachepolicy's op te halen en te converteren.  Afbeelding 2 toont de instellingen voor de cachepolicy's. 
 

07/18/12  5:16:37: EVT#28008-07/18/12 5:16:37:  54=Policywijziging op VD 00/0 naar [ID=00,dcp=0d,ccp=0d,ap=0,dc=0,dbgi=0] van [ID=00,dcp=0d,ccp=0c,ap=0,dc=0,dbgi=0] 

Afbeelding 2:  Voorbeeld van uitvoer van controllerlogboeken met wijzigingen in cachepolicy

De Default Cache Policy (DCP) is de cachepolicy die is ingesteld toen de array werd gemaakt, of die op een bepaald moment handmatig is ingesteld door de gebruiker.  De Current Cache Policy (CCP) is de cachepolicy die momenteel wordt gebruikt op basis van de automatische reactie van de controller op een specifieke gebeurtenis. 

Elke bit in een datawoord van 4 bits staat voor een andere functie.  Het bitmasker wordt gebruikt om de betekenis van elk bit te bepalen.  Afbeelding 3 toont de correlatie tussen de binaire waarden en de cachepolicy-instelling per bit.
 

Afbeelding 3:  Bitmaskerwaarden en -betekenissen voor elk bit.