Bakgrunn.

Jeg innstallerte en solid-state drive (SSD) som systemdisk høsten 2009 og var søkkfornøyd med ytelsesforbedringen den ga. Maskinen bootet minst dobbelt så raskt og applikasjonene (spesielt openoffice) spratt opp nesten uten forsinkelse. Høsten 2010 fikk jeg en følelse av at maskinen ikke var fullt så snappy som før. Var jeg bare blitt blasert eller hadde SSDen blitt betydelig tregere? Siden man må putte tall bak synsingen sin dro jeg frem min favoritt io-benchmark, iozone, og ganske riktig, ytelsen hadde falt dramatisk. Skriveytelsen hadde gått ned fra 150-200MB/s til 47MB/s og leseytelsen hadde falt fra 200MB/s til 100MB/s. SSDen var nå tregere enn harddisken i maskinen på sekvensiell io! På random io var ikke tallene så ille, men fortsatt en betydelig degradering.

Teknisk beskrivelse.

Problemet med ytelsesdegradering over tid er velkjent og er forårsaket av hvordan flash-minneceller virker se denne artikkelen for mer informasjon enn du noensinne vil vite om SSD og flash-teknologi. Kort fortalt er problemet at nand-flash lagrer data i blokker på 512KB og når du vil endre en byte informasjon må hele blokken leses, endres og skrives tilbake. SSD firmware har avanserte algoritmer for å holde flest mulig blokker ledig for å holde ytelsen oppe, men trenger informasjon fra OSet om hvilke byteranges som er ledig. Dette blir gjort gjennom noe som kalles en TRM kommando hvor OS-et gir beskjed til disken når en fil blir slettet slik at SSD-disken har bedre oversikt over ledige blokker. Man trenger et OS som støtter TRM, oppdatert Windows7 og Linux > 2.6.32 har TRM support. (Jeg antar at alle vet at når man sletter en fil blir normalt sett ikke informasjonen i fila fysisk slettet fra disken, kun linken til fila blir fjernet. Hvis dette er overraskende nytt for deg bør du vurdere om du har noe på ITA å gjøre;-) I tillegg må selvfølgelig SSD-fw ha støtte for TRM. Min SSD hadde det ikke og trengte en FW-oppgradering (dette var ganske trøblete se nedenfor). Etter FW oppgradering til v2.0 fikk SSD-en min TRM support og alt var fryd og gammen igjen, trodde jeg. Disken var rask og fin i begynnelsen, men jeg fikk en mistanke om at den ble tregere og tregere igjen, hmm, ut og grave på nettet igjen.

OS support for TRM.

Det viser seg at man trenger et spesielt mount flagg, discard, for at linux-kjerna skal sende TRM info til disken, se her for mer info.
Jeg fant også en plass at det kan være lurt å sette flagget noatime for å forhindre at systemet skriver last access time til en fil for hver gang den blir lest. Så her er mount linja jeg bruker i fstab:

/dev/sda1 / ext4 noatime,discard 1 1

Men dette hjelper ikke umiddelbart på ytelsen siden systemet kun sender TRM-info når du sletter filer. Den optimale løsningen er selvfølgelig å reformattere hele disken og reinstallere systemet med de nye mount-flaggene, men jeg er blitt for gammel og synes ikke slikt er morsomt lenger. En mellomløsning er å skrive en stor fil til all ledig diskplass på hver partisjon for så å slette den igjen. Da vil OS-et sende TRM-info om all ledig plass på partisjonen og SSD-en kan da få informasjon om ledige celler som den kan skyfle informasjon rundt på. Dette hjelper faktisk betydelig på ytelsen, write ytelsen gikk opp fra 55 til 150 MB/s og read opp fra 110 til 205 MB/s.

Benchmarks:

SSD ytelse ved forskjellige konfigurasjoner.

Forklaringer

• hd: harddisken på systemet, 2x1TB Seagate Barracude 7200rpm som er speilet. Kun tatt med som en baseline for vanlige harddisker. Dato. 29. sep. 2010
• ssd fw1.0 used: SSD ytelsen når jeg først fikk mistanke om degradering av ytelse. Dato: 29. sep. 2010
• ssd fw2.0 fresh: Blank SSD med ny FW. Dato: 2. nov. 2010
• ssd fw2.0 used: ytelsen når jeg fikk mistanke om degradering 2. gang. Dato: 10. jan. 2011
• ssd fw2.0 with TRM and discard: Ytelse etter at jeg hadde montert diskene med noatime og discard flagg. Som man ser hjelper ikke dette i særlig grad. Dato: 25. jan. 2011
• ssd fw2.0 after big file write&delete: Ytelse etter å ha fylt ledig plass med en stor fil som man så sletter igjen. YIHAA, back in business! Dato: 25. jan. 2011

Random read har mest å si for tiden det tar å starte applikasjoner. Random write ytelsen spiller en stor rolle når du kjører software oppdateringer, det har vi endel av på Fedora…

Oppsummering.

Man kan forbedre ytelse og levetid på solid-state disker med å bruke de riktige mount-flagg, OS og SSD som støtter TRM.

Hva trengs?

1. SSD med riktig FW.
2. Oppdatert OS.
3. discard og noatime mount flagg.
4. Enten reformattere disken eller fylle den med en stor fil som man sletter etterpå

Appendikser:

Skrive store filer:

jeg bruker iozone:


iozone -s 14g -r1m -i0


Skriver 14GB til en fil i 1MB blokker og sletter den igjen.

dd fungerer fint også:


dd if=/dev/zero of=bigfilewithzeros bs=1024 count=14000000
rm bigfilewithzeros


Hvordan sjekke at TRM virkerlig er aktiv?

Når du sletter en fil sender kjerna beskjed om at en byte-range er blitt ledig til SSD-en. System monitorer registrerer dette som write-aktivitet og du kan se dette med verktøy som f.eks. dstat. Her er en listing fra dstat på slutten av en iozone run der den har skrevet en 14GB fil og deretter sletter den:

----total-cpu-usage---- -dsk/total- -net/total- ---paging-- ---system--
usr sys idl wai hiq siq| read  writ| recv  send|  in   out | int   csw 
  1   2  85  12   0   0| 140M    0 |1249B    0 |   0     0 |1794  3517 
  1   2  87  10   0   0| 138M    0 | 552B    0 |   0     0 |1885  3523 
  1   2  86  11   0   0| 131M   36k|1371B    0 |   0     0 |1722  3390 
  1   2  86  10   0   0| 139M    0 |1028B    0 |   0     0 |2077  3560 
  1   2  86  11   0   0| 137M    0 | 725B    0 |   0     0 |2036  3536 
  1   2  86  10   0   0| 142M    0 |1164B  887B|   0     0 |2096  3656 
  1   2  84  13   0   0| 146M 4096B|1867B  172B|   0     0 |1868  3743 
  1   2  87  10   0   0| 148M    0 |1068B  392B|   0     0 |1948  3680 
  1   2  86  11   0   0| 146M 4096B| 428B   46B|   0     0 |1912  3733 
  1   2  86  11   0   0| 141M    0 | 548B  196B|   0     0 |1813  3541 
  1   2  86  11   0   0| 116M   76k| 474B    0 |   0     0 |1708  3220 
  1   3  85  11   0   0| 152M    0 | 816B    0 |   0     0 |2006  3779 
  1   2  86  11   0   0| 144M    0 | 658B   66B|   0     0 |1877  3644 
  1   2  84  13   0   0| 126M  116k| 888B    0 |   0     0 |1777  3452 
  2   2  85  11   0   0| 145M    0 | 893B    0 |   0     0 |2036  4438 
  1   3  86  10   0   0| 147M   40k| 779B  196B|   0     0 |1951  3914 
  1   3  84  12   0   0| 142M   20k| 312B    0 |   0     0 |1939  4210 
  1   8  91   0   0   0| 116k    0 | 683B  392B|   0     0 |1270  1377 
  1   0  99   0   0   0|   0   129M| 363B    0 |   0     0 | 619  1074 
  2   1  98   0   0   0|   0   312M| 482B  196B|   0     0 | 616  1103 
  1   1  98   0   0   0|   0   617M| 120B    0 |   0     0 | 679  1052 
  1   1  98   0   0   0|   0   680M| 272B    0 |   0     0 | 670  1094 
  1   1  99   0   0   0|   0   768M| 882B    0 |   0     0 | 620  1048 
  2   1  98   0   0   0|   0   744M|1424B   66B|   0     0 | 637  1117 
  1   1  97   1   0   0|4096B  768M| 484B    0 |   0     0 | 543  1060 
  2   1  98   0   0   0|   0   768M| 521B  196B|   0     0 | 654  1165 
  1   1  98   0   0   0|   0   768M| 244B    0 |   0     0 | 547  1093 
  2   1  98   0   0   0|   0   768M|1689B  392B|   0     0 | 651  1136 
  1   1  98   0   0   0|   0   768M| 757B  163B|   0     0 | 633  1058 
  2   1  97   0   0   0|   0   768M|1573B  196B|   0     0 | 734  1099 
  1   1  99   0   0   0|   0   760M| 710B    0 |   0     0 | 639  1043 
  1   1  98   0   0   0|   0   768M| 860B    0 |   0     0 | 735  1062 
  1   1  98   0   0   0|   0   768M|1702B    0 |   0     0 | 778  1066 
  2   1  97   0   0   0|   0   632M|1190B    0 |   0     0 | 829  1168 
  1   1  98   0   0   0|   0   624M|1109B    0 |   0     0 | 668  1078 
  1   1  98   0   0   0|   0   832M|1635B  196B|   0     0 | 915  1180 
  1   1  98   0   0   0|   0   728M|1922B    0 |   0     0 | 797  1120 
  2   1  98   0   0   0|   0   376M|1454B  392B|   0     0 | 858  1143 
  1   1  99   0   0   0|   0   272M|1324B  284B|   0     0 | 776  1126 
  1   1  98   0   0   0|   0   656M|1685B  196B|   0     0 | 825  1096 
  1   0  99   0   0   0|   0    64M| 824B    0 |   0     0 | 712  1078 
  1   0  98   0   0   0|   0     0 |1351B  330B|   0     0 | 828  1112 
  1   1  99   0   0   0|   0     0 |1801B    0 |   0     0 | 722  1070 
  1   1  98   0   0   0|   0     0 | 848B    0 |   0     0 | 744  1059 
  1   0  99   0   0   0|   0     0 | 908B    0 |   0     0 | 698  1050 
  1   0  98   0   0   0|   0     0 | 940B  196B|   0     0 | 784  1133 
  1   0  99   0   0   0|   0     0 | 336B    0 |   0     0 | 719  1058 

Som man ser får man en skikkelig flare av write-io når fila er ferdig lest og skal slettes.

Oppgradere FW på SSD.

Min systemdisk er en Corsair Extreme Series X64 og en eller annen hos Corsair må ha hatt en dårlig dag på jobben da denne ble godkjent for salg. Det viser seg at den ble solgt med en firmware v1.0 uten støtte for TRM, videre klarer ikke Corsair å lage en firmware oppgraderingsprosess som som passerer deres egne kvalitetstester! Jeg tror aldri jeg har sett så mye banning i et supportforum… Corsair har nå sluppet en firmware upgrade program med klausul at denne kan ødelegge data på SSD-en. Rettelse, de har sluppet 8 forskjellige, to for hver SSD størrelse, hvor du bruker den ene eller den andre alt ettersom det står Corsair eller CORSAIR i hw-info (bruk hdparm -I /dev/sdX for å sjekke). Og du kan bricke disken hvis du flasher feil firmware! For å gjøre en lang historie kort: Det var plent umulig å få til å oppgradere FW så jeg måtte sende disken til Nederland for å få dette ordnet. Corsair har en supportside hvor du kan be om å få dette gjort.