Nou, ik niet eerlijk gezegd. Een groot deel van je OS en apps zijn statische data en gaan niet snel veranderen. Als daar niet aan gedacht is, dan kunnen fabrikanten geen 3 jaar garantie geven op die dingen.
[...]
Net zoals het voorgaande: geen idee of dat zo is. Jij hebt blijkbaar een bron - waar ik erg nieuwsgierig naar ben - waar dat staat.
Voor mij staat nl. niet vast dat per block of whatever apart een tellertje wordt bijgehouden (bij elke write weer een extra write!). Of dat er een wat grover algorithme werkzaam is. Ik kan meerdere mechanisme bedenken.
Nou ja, het is meer common sense. Ik heb geen bron waar dat letterlijk in staat nee, maar ik heb wel ervaring met het ontwerpen van embedded systems.
Het is aan te nemen dat de controllers een deel van het flash gereserveerd hebben voor het opslaan van tabellen en andere data betreffende de staat van het flash. Als je 80GB flash hebt, kun je best 32MB reserveren voor system data. Dat hoeft dan ook niet gewist te worden bij een firmware flash of full erase. Mocht er geen wear data per block worden bijgehouden (wat ik me wel kan voorstellen, reken maar eens uit hoeveel data dat kost) dan zou je nog altijd de kwaliteit van het flash kunnen meten door de voltage drop te meten per cell in een block. Ik weet niet in hoeverre dat ook te doen is, dat ligt mede aan de flashchips denk ik.
Dat vind ik het irritante aan het hele SSD gebeuren. Hoe het écht precies werkt kan ik niet vinden.
Bijv. waarom het Intel algorithme blijkbaar wel zo slim is om een wipertooltje minder nodig te maken.
Hoe die garbagecollection werkt. Etc, etc.
Er is een pool aan stellingen die regelmatig herhaald worden ("intel heeft minder schrijfperformancedegradatie"). Maar ik wil eigenlijk veel meer de diepte informatie. En die vind ik nergens. Die SSD's zijn nog veel te veel black-box naar mijn zin
Dus diepte-info: ik hou me aanbevolen!
Bij de Vertex valt enige prformance drop meteen op doordat deze geen cap op de sustained write heeft. De Intel MLC's hebben een cap van 70-90MB/s sustained, deze zul je dus ook niet zo snel in zien zakken omdat ze altijd wat achter de hand hebben.
De garbage collector zal waarschijnlijk de schijf aflopen en kijken welke flash blocks maar gedeeltelijk aan LBA adressen gelinkt zijn, en de nog lege pages vullen met data uit andere half gevulde flash blocks. Elke compleet invalid gemarkeerde block is er weer 1 waar full speed naar geschreven kan worden. Omdat er nogal wat flash blocks op een schijf zitten, kan dit proces aardig wat tijd kosten. Er kan vast wel wat gestoeid worden met intelligende algoritmes en de LBA -> flash link tabel om het compleet scrubben van de SSD overbodig te maken.
Als een SSD een aardig stuk flash achter de hand heeft als scratch buffer, dan zal met een goede garbage collector de TRIM functie nagenoeg overbodig zijn. Heb je geen scratch buffer, dan holt de performance achteruit zoveelte voller de schijf is. Dan is TRIM gewoon een must. Elke LBA sector die als leeg gemarkeerd wordt door een TRIM commando is beschikbaar als scratch buffer namelijk.
Intel heeft waarschijnlijk al ver van tevoren aan zien komen dat SSD's op een dag betaalbaar zouden zijn, en het zou me ook niets verbazen als ze een jaar of 4-5 terug al zijn begonnen met de eerste ontwerpen voor wat nu de postville controller is. Daarom verbaast het me niets dat ze een betere garbage collector hebben, dit is iets wat je pas later in het ontwikkelstadium toe voegt. De Barefoot was nog lang niet feature complete toen OCZ ze op de makrt bracht, en dat hebben we allemaal kunnen zien door de datacorruptie verhalen her en der.
Black boxes zullen het altijd wel blijven, het is tenslotte geen open source...