OCZ Vertex 2E SATA II 2.5" SSD 60GB

Ik had deze SSD voor mijn laptop gekocht en het bleek tijdens en na installatie een grote teleurstelling.
update: zie onder

Past niet in harddisk cage
Allereerst past hij niet in de harddisk cage van mijn Thinkpad. Alle vijf 2.5" harddisks die ik hier heb passen als gegoten, maar de OCZ is gewoon ongeveer een milimeter te breed en ongeveer 2mm te kort. Hoe doe je dat OCZ? Er zijn toch specs voor de grootte van een 2.5" disk? Ik heb dit 'opgelost' door de cage weg te laten en hem maar gelijk in het rubberen hoesje te steken. Zelf heb ik met plakband een lipje gemaakt om hem er ooit weer uit te kunnen halen.

Ik mis 5GB!?
Vervolgens ging ik Ubuntu Linux installeren. Al bij het partitioneren kwam ik erachter dat ik 5GB mis op de geadverteerde capaciteit. Ja, dat is met correctie op de GB vs. GiB. Mijn andere harddisks laten in de Ubuntu installer altijd de juiste geadverteerde capaciteit zien. Toch doorgegaan met encryptie (dm-crypt) op /home (40GB) en de rest zonder encryptie op / (15GB).

Data wegschrijven: nullen t.o.v. echte files
Het deel van het installeren waar de pakketten worden uitgepakt ging niet bepaald merkbaar sneller dan op mijn gewone harddisk. Eenmaal alles geïnstalleerd heb ik wat benchmarks gedaan (hdparm, dd met oflag=direct) waaruit toch wel de kern van de slechte prestaties uit naar voren komt: comprimeerbare data (bijv. allemaal nullen) sequentieel wegschrijven gaat snel met 125 MB/s (limiet is mijn SATA-1 controller cap van Lenovo), oncomprimeerbare data (bijv. een GPG-geëncrypte file) sequentieel wegschrijven gaat met een maximum van 28,1 MB/s (t.o.v. ~50 MB/s met mijn normale harddisk).

Dat oncomprimeerbare data wat langzamer gaat was mij bekend van het design van de Sandforce SF-1200 controller die OCZ gebruikt, maar dat het factor 10 (!) van de geadverteerde schrijfsnelheid (275 MB/s) af zou liggen vind ik onbehoorlijk en zwaar misleidend.
update: zie onder

Data lezen: sequentieel OK, random NOT OK
Sequetieel data lezen gaat zeer rap, dus mijn boottijden zijn er enorm op vooruitgegaan. Random reads vind ik nog erg tegenvallen. Een 'svn st' op een wat grote repo duurde op mijn oude laptopharddisk ~60 seconden en op mijn SSD is dat min of meer gelijk. Tegelijk zie ik onwijs veel I/O wait op de CPU en met iostat komt de SSD niet verder van 110 reads/s (t.o.v. ~100 reads/s van mijn normale harddisk).
update: zie onder

De oorzaak: 25nm model
Zo ongeveer tegelijk met deze zeer teleurstellende constatering van dit product werd op T.net een nieuwtje bekend: 'OCZ's Vertex 2-ssd's met 25nm-geheugen presteren slechter'. Ik had inderdaad een dergelijk model (de firmware is bij levering al versie 1.28) dus dat verklaarde waarom ik dergelijke resultaten behaalde en waarom 5GB van de geadverteerde capaciteit niet beschikbaar is.

Verwachtingen t.o.v. uitkomsten
Wat had ik verwacht voordat ik het product kocht?

• Dat sequentiële lees- en schrijfsnelheden werden beperkt door de cap van Lenovo op mijn SATA controller: bruto 150 MB/s.
• Dat ik een enorme verbetering zou zien in random reads en random writes ten opzichte van mijn 5400rpm laptopdiskje.
• Dat hij op een fatsoenlijke manier zou passen in mijn laptop.
• Dat met deze SSD de CPU de limiterende factor zou zijn voor het schrijven van data op mijn /home (dm-crypt).

Wat kreeg ik na installatie?

• Sequentiële read is nu beperkt tot de controller cap.

Conclusie
Een grote teleurstelling. Het advies van Lenovo op de community forums was om een Samsung SSD te kopen; had ik dat maar gedaan.
Ik ben zelden zo negatief over een product, maar deze actie van OCZ heeft mijn vertrouwen in het merk volledig geschaad.
update: Nog steeds negatief, maar de snelheid is nu in de praktijk redelijk op orde. (zie onder)

Update 2011-06-04
Inmiddels heb ik de SSD een volledige reset gegeven (ATA Security password setten en weer resetten). Vervolgens een firmware update naar 1.33 en de snelheid is voor mij een heel stuk verbeterd. Met name random lezen/schrijven van random, niet-comprimeerbare data (de geëncrypte partitie) is nu beperkt tot mijn CPU.
Een praktijkvoorbeeld is het commando "svn st" in dezelfde grote subversion repository checkout is van ~60 seconden met 95% CPU-waiting naar rond de zes seconden gegaan met véél minder CPU-waiting time.

Welke van de twee acties precies de oorzaak van de traagheid hebben weggenomen is mij niet duidelijk, ik heb ze tegelijk uitgevoerd, maar het is dus raadzaam om zowel de firmware update uit te voeren als de reset, zo blijkt.

Update 2011-01-06
De SSD is er plots mee opgehouden, met SATA link errors in de kernel log. Ook in een andere PC is er geen leven meer in te krijgen. Onbetrouwbaar dus door falen < 1 jaar na aanschaf.