Dat ligt idd puur aan de controller. Nu moet je wel weten dat je in een SSD, en zeker al niet in een MLC SSD, niet zomaar data kan wegschrijven waar er plaats is, zoals een HD doet. Om te beginnen heeft iedere cel in een MLC SSD vier spanningsniveau's en toestanden (00, 01, 11, 10) omdat er twee bits per cel kunnen worden weggeschreven. Een traditionele HD of een SLC SSD hebben maar twee states: 1 of 0. Bij het lezen en schrijven van MLC duurt het dus wel een eindje voor de controller de precieze staat van de cel bepaald of geschreven heeft (maar wel nog steeds véél minder lang dan bij een HD).
Daarnaast is er ook de opbouw van de SSD waar rekening mee gehouden moet worden. De cellen worden gegroepeerd in pages. In de meeste MLC SSD's is zo'n page 4 KB groot. Dit is de kleinste hoeveelheid data die je kan wegschrijven, vergelijkbaar met clustergrootte bij HD's (2 KB zal dus ook een page van 4 KB innemen). De pages worden echter op hun beurt nog eens gegroepeerd in blocks, die bestaan meestal uit 128 pages ofte 512 KB. Een block is de kleinste hoeveelheid data die gewist kan worden.
Je kan dus schrijven per 4 KB, maar slechts wissen per 512 KB. Dat schept natuurlijk een aantal problemen. Als je een file van pakweg 8 KB wil deleten zou de SSD dus de volledige block van 512 KB moeten wissen, wat natuurlijk voor verlies van alle andere data in die block zou zorgen. De controller moet dus de te deleten pages aanmerken als ongeldig en in het oog houden wanneer het aantal ongeldige pages in een block te groot wordt. Dan kan hij een aantal van die blocks in het geheugen lezen en alle geldige data en alle te deleten data groeperen, zo komen er terug blocks vrij.
Erger wordt het als je een wijziging van enkele KB's in een file wil doen. De controller moet dan de hele block waarin dat bestandje zich bevindt in het geheugen inlezen, de wijziging doorvoeren en dan alles terug naar de block kopiëren (aangezien je slechts per block kan wijzigen). Een write van 4 KB kan dus een effectieve write van 512 KB opleveren. Dit noemt men write amplification.
Slechte controllers hebben veel last van die write amplification. Bij kleine writes, bvb random I/O's van je OS, wordt er in de SSD wel degelijk heel veel data verzet. Dit kan voor vertragingen zorgen. Door een bug in de JMicron controller wordt dit echter nog erger: er is blijkbaar een probleem met de controllercache waardoor heel het proces van lezen-aanpassen-herschrijven bijzonder traag verloopt, nog veel trager dan je zou verwachten. Dat resulteert in die lagstoten tot 2s.
De controller moet overigens nog heel wat andere zaken doen. Aangezien flashcellen maar 10.000 maal herschreven kunnen worden moet de controller op een intelligente manier data spreiden over zoveel mogelijk cellen, zodat deze allemaal gebruikt worden. Als je een aantal blocks deleted zullen die niet onmiddellijk weer gebruikt worden, de controller zal eerst de cellen die nog nooit gebruikt zijn beschrijven. Pas als iedere cel één maal beschreven geweest is zal er een tweede cyclus starten, etc ... Dit noemt men wear leveling, het spreiden van het verslijten.
In een SSD zit er dus heel wat technologie die je op het eerste gezicht niet zou verwachten. Zeker de controller is een technologisch hoogstandje, deze moet de 'domme' flash cellen op een zo goed mogelijke manier aansturen. Je mag nog de snelste cellen ter wereld gebruiken, uiteindelijk ligt het aan de controller hoe snel je SSD zal zijn (en hoe lang ie zal meegaan).