OCZ en Indilinx krikken ssd-prestaties op met nieuwe firmware

Hardwarefabrikant OCZ heeft in samenwerking met halfgeleiderproducent Indilinx een firmware-update ontwikkeld voor solid state drives die de Barefoot-controller gebruiken. De drives zouden dankzij de update aanzienlijk sneller worden.

De prestaties van solid state drives worden na verloop van tijd minder, omdat het aantal ongebruikte geheugenblokken afneemt. Alle geheugenblokken die al eens gebruikt zijn, moeten eerst worden gewist voordat ze hergebruikt kunnen worden en dat drukt de prestaties aanzienlijk. Vrijwel alle ssd's vertonen dan ook prestatiedegradatie. In samenwerking met Indilinx, de fabrikant die onder meer de Barefoot-ssd-controller maakte, heeft OCZ nu een firmware ontwikkeld die de prestaties van zijn solid state disks op niveau moet houden.

De nieuwe firmware voor de Indilinx Barefoot-controller zou de prestaties van alle drives in de Vertex-serie verbeteren. Zodra de ssd in idle-staat verkeert, worden gebruikte maar vrijgegeven geheugenblokken geleegd, zodat daar met dezelfde snelheid naar kan worden geschreven als bij een nieuwe drive.

De website HotHardware kreeg een Vertex-ssd met de nieuwe firmware in handen en testte de effecten van de verbeterde garbage collection, zoals deze feature heet. Na vijf minuten in de idle-stand was de Vertex al bijna tot in nieuwstaat hersteld; na een uur idle'n bleek de schijf weer volledig als nieuw te presteren. Het is nog niet bekend wanneer de firmware voor het publiek beschikbaar zal worden.

Reacties (101)

[pm1]

mm deze firmware heeft ook wel een negatief kantje:

op een HDD als je vroeger iets verwijderde werd dit uit de index gewist maar nog niet overschreven: gevolg je kan het bijna altijd nog recoveren.

bij SSD's was dit voor deze firmware ook hetzelfde, maar nu zal je data die je per ongeluk gewist hebt ook daadwerkelijk ineens weg zijn doordat hij automatisch de ruimte overschrijft met nullen.

[LvdBlom]

Het is daarom te hopen dat de firmware slim genoeg is om eerst te wachten met z'n opschoning. Immers, als je een bestand per ongeluk verwijdert, dan wil je 'm ook zo snel mogelijk terug. Door een minimum idle-time in te voeren, is dat prima mogelijk, want het lijkt me sterk dat je je bestand na één dag of zo pas probeert terug te halen. Zodra de SSD 5 minuten (of iets dergelijks) lang idle is geweest, dan pas zou de firmware kunnen beginnen met het opschonen. Mits je goed gewapend hebt tegen zo'n incident (dus dat je een recoverprogramma bij de hand hebt), kun je 't best snel herstellen. En ach, anders zijn er ook manieren om de SSD bezig te houden terwijl je op zoek gaat naar een recoverprogramma.

Helaas wel dat de Tweaker dit soort zaken wel kent, maar niet de gemiddelde consument. Dus voor het laatste is dit inderdaad een groter risico.

[ByteDelight]

Zit wel wat in, maar feit blijft dat de kans bestaat dat je verwijderde data ook echt niet meer kunt terughalen.

Het is dus aan de gebruiker daar BETER mee om te gaan: vaker de prullenbak gebruiken en op passen wat je verwijdert.

[LvdBlom]

Precies. Toevallig heb ik net ook hetzelfde geschreven bij de reactie van jacovisscher hieronder.

[Gumuz]

Hoe vaak heeft een van jullie geprobeerd om bestanden die echt gewist zijn terug te vinden? (bij een harddisk kan dit ook als de sectoren al een keer overschreven zijn)
Het is mogelijk maar je moet wel erg thuis zijn in dit soort software om het ook echt te gebruiken.
Daarnaast is het zo dat als je over deze kennis beschik je waarschijnlijk ook zo IT-savvie bent dat je het nog op een backup hebt staan. Er zijn immers meer dingen die fout kunnen gaan op een hd naast perongeluk deleten..
Dus hoewel dit theoretisch een nadeel zou kunnen zijn, is het wel heel hypothetisch. Het lijkt het mij in de praktijk niet een bezwaar.

[joppybt]

Volgens mij ben jij nu in de war met het implementatie van het TRIM-commando die dit inderdaad als consequentie kan hebben.
De defragmentatie hier heeft geen invloed op blokken waarvan alleen het operating systeem denkt/weet dat ze leeg zijn.

[Martin-S]

Inderdaad, dat zou een probleem kunnen zijn.

Zorgen dat je recente (externe) backups van de betreffende data hebt. Aangezien het me logisch lijkt dat een SSD vooral als systeem drive wordt gebruikt (dat zou bij mij wel het geval zijn.), is dat toch vaak wel het geval.

[jacovisscher]

Daarom is er een prullenbak...

[LvdBlom]

Dat klopt. In dit geval is zoiets wel handig, maar er zijn mensen (lees: ik) die de prullenbak niet zo graag mogen en liever Shift + Del gebruiken. Die aanvaarden dan ook het risico dat erbij hoort, en dan is deze nieuwe firmware iets minder handig.

Maar ach, bij mij is het al járenlang goed gegaan met deze methode van verwijderen. Ik heb nooit iets per ongeluk verwijderd. Een ongelukje zit altijd in een klein hoekje (daarom even afkloppen ), maar ik vind het een verwaarloosbaar klein risico. En anders moet je er maar een gewoonte van maken dat je voortaan bestanden naar de prullenbak stuurt als je deze firmware hebt in plaats van ze gelijk permanent te verwijderen.

[Mentalist]

Een SSD "weet" volgens mij helemaal niet welke blokken er leeg mogen. Als je een bestand wegmikt blijft normaal de data er ook gewoon opstaan, alleen de link erheen verdwijnt en je filesystem markeert dat stukje drive als "beschikbaar" voor nieuwe files.

Maar dat markeren van je FS is totaal onzichtbaar voor een SSD. Die ziet alleen maar enen en nullen. Je SSD "weet" niet dat jij een file hebt weggemikt, dat weet alleen je FS.

Het lijkt me dus ook dat deze feature onmogelijk kan werken zonder TRIM?

[Pinkys Brain]

De metadata van de FS staat meestal wel op de schijf, en er zit waarschijnlijk gewoon een programmeerbare uC in de controller. Ik denk dat ze specifieke code voor NTFS hebben ingebouwt die met behulp van die data trimmed, anders zie ik niet in hoe het zou moeten werken.

Dat zou echter wel betekent dat het filesystem afhankelijk is en niet gaat werken met RAID.

[Reactie gewijzigd door Pinkys Brain op 22 juli 2024 22:15]

[Femme]

Garbage collection heeft in dit geval niets te maken met het bestandssysteem. Het gaat om het verminderen van de fragmentatie van geheugenblokken in het flashgeheugen zoals anderen reeds uitvoerig hebben uitgelegd. Door geheugenblokken met volledig incourante gegevens te wissen voordat ze herbeschreven worden en door de geldige inhoud van volgeschreven geheugenblokken met gedeeltelijk incourante gegevens samen te voegen ontstaan er meer lege geheugenblokken die snel beschreven kunnen worden.

De feature staat los van het trim-commando maar zorgt er wel voor dat trim optimaal zal functioneren. Beide technieken zullen de performance-degratie van ssd's fors verminderen.

[mjtdevries]

Waaruit concludeer jij dat er sprake zou zijn van het verminderen van de fragmentatie van geheugenblokken in het flashgeheugen?

Het artikel hier op T.net heeft weer eens geen bronvermelding waar ik het zou kunnen verifieren, en in de test waar naar verwezen wordt is ook helemaal niets te vinden wat aanleiding geeft tot die claim.

Ik zie in die test alleen een indicatie dat er sprake is van de normale garbage collection zoals de betere merken al lang toepassen op SSDs, maar helemaal niets dat wijst op defragmentatie.

[Femme]

Wat versta jij onder 'normale garbage collection'?

De informatie over de werking van de garbage collector in de firmware van Indilinx is summier maar lijkt erop te wijzen dat de garbage collector geheugenblokken met gedeeltelijk geldige data samenvoegt zodat er meer lege geheugenblokken beschikbaar komen en de ongebruikte capaciteit van de ssd wordt gedefragmenteerd.

Met defragmentatie bedoel ik in dit geval dus niet defragmentatie van bestanden.

PC Perspective schrijft:

This feature is supposed to take advantage of idle time by undoing the fragmentation previously caused by combined writes.

Hothardware.com schrijft:

A common concern with the current crop of Solid State Drives is the performance penalty associated with block-rewriting. The flash memory used on today's SSDs is comprised of cells that usually contain 4KB pages that are arranged in blocks of 512KB. When a cell is unused, data can be written to it relatively quickly. But if a cell already contains some data--no matter how little, even if it fills only a single page in the block--the entire block must be re-written. That means, whatever data is already present in the block must be read, then it must be combined or replaced, etc. with the new additional data, and the entire block is then re-written. As you can surmise, this process takes much longer than simply writing data straight to an empty block.

This isn't a concern on fresh, new solid state drives, but over time, as files are written, moved, deleted, replaced, etc., many blocks are a left holding what is essentially orphaned or garbage data and their long-term performance degrades because of it.

To mitigate this problem, virtually all SSD manufacturers have incorporated, or soon will incorporate, garbage collection schemes into their drives' firmware that actively seek out and remove the garbage data.

[Reactie gewijzigd door Femme op 22 juli 2024 22:15]

[eymey]

Dat vraag ik mij nou inderdaad af. Of monitort de firmwar evan de drive zelf ook 'slim' de index records van het FS? Dat laatste lijkt me onwaarschijnlijk, dan moet hij wel erg veel van alle FS' en weten (of het wordt alleen voor bepaalde FS' en ondersteund).

Vraag me dus ook af hoe men dit doet....

[Verwijderd]

Ht werkt niet op file-niveau maar op blok-(groepje cellen) niveau. De firmware op de schijf houd bij in welke blokken incourante data staat, maar kan deze niet hergebruiken totdat ze electrisch gewist zijn. (alle cellen van lading ontdaan)
Ze kunnen in een ssd nl alleen 1en schrijven, en geen 0en van een 1 maken...

[ls470]

Bij iedere SSD moeten de geheugenblokken gewist worden voor ze hergebruikt worden; het enige verschil is dat't nu in idle tijd gebeurt ipv tijdens het schrijven naar de SSD; deze firmware verandert dus niets aan dat probleem.

Een SSD heeft dus altijd een stuk extra ruimte (niet zichtbaar voor het OS) om zijn data te kunnen verplaatsen en opruimen. Hoe meer extra ruimte, hoe gemakkelijker het voor de controller is om op te ruimen en hoe hogere schrijfprestaties mogelijk zijn. (zou het ook niet daarvoor zijn dat die Vertexten 60GB en 120GB ipv 64GB en 128GB groot zijn? )

Door het TRIM commando krijgt de controller NOG meer vrije ruimte om mee te spelen bovenop zijn eigen privéruimte; met TRIM en een vrij lege schijf is deze aanpassing relatief minder belangrijk...

[Verwijderd]

Om nog even terug te komen op het van invloed zijn op de levensduur, ik denk wel dat dit een negatieve invloed op de levensduur heeft.

Stel je eens even voor:

de oude situatie: een blok wordt gemarkeerd als "moet gewist worden". (een schrijfactie waar bv een byte wijzigt, maakt een heel blok "ongeldig", en het gehele gewijzigde blok wordt in een ander, nog leeg blok weggeschreven.)
Als er nog andere schrijfacties komen, wordt dit hele blok niet meer gebruikt, en blijft staan, totdat ALLE blokken op de hdd al een keer beschreven zijn. Daarna moet een "blok erase"kommando uitgevoerd worden, voordat er gegevens weggeschreven kunnen worden, dit is de de zogevreesde performance degradatie bij ssd's. Hierna worden alle blokken pas voor de 2e keer beschreven, tot ze allen weer een keer gebruikt zijn enz.

De nieuwe situatie: een blok wordt gemarkeerd als "moet gewist worden", zie hierboven.
Als de schijf idle is wordt dit gelijk gewist, en kan GELIJK weer gebruikt worden. Dus lang voordat de schijf ook maar vol is wordt dit blok al 2 keer gebruikt, en omdat er vaak de zelfde bestanden gewijzigd worden, dus steeds de zelfde blokken worden beschreven, en weer gewist, kunnen sommige stukken van de ssd honderden, zoniet duizenden keren opnieuw gebruikt worden, terwijl andere stukken van de harddisk ALTIJD leeg zijn.

Als je bedenkt dat een ssd cel maar een paar duizend keer gewist en weer geschreven kan worden, hebben ze volgens mij het hele wear leveling mechanisme getorpedeerd.
Omdat ik me niet kan voorstellen dat ze stom zijn daar bij OCZ en indilinx,moet er nog iets zijn wat ze niet vertellen. Bv dat dit "trimmen" pas gebeurt als bijna alle blokken op zijn, en er nog een hele hoop gewist kan worden.

Een ideale "trim" wordt dus m.i. pas uitgevoerd als alle vrije blokken bijna op zijn, dus vlak voordat performance degradatie plaats vind. Want hoe langer je wacht, hoe beter het schrijven verdeeld wordt over alle cellen, en hoe minder sommige cellen moeten worden gemarkeerd met "permanent onbruikbaar" omdat hun maximale beschrijfbaarheid overschreden is.

Als ik e e a niet goed begrepen heb aangaande ssd theorie, hoor ik dat graag...

[Martin-S]

Je hebt een punt, maar misschien hebben ze dit voorzien en onthoudt de schijf de "schrijfvolgorde" alsnog en worden de geleegde blokken pas opnieuw gebruikt als ALLE blokken een keer gebruikt zijn.

[edit] oftewel: zoals joppybt al zegt, gaat de schijf wss eerst verder via het normale algoritme.

[Reactie gewijzigd door Martin-S op 22 juli 2024 22:15]

[Chovav]

@ racer13 waarschijnlijk niet veel, aangezien die blokken toch al vrij waren en gewist moeten worden voordat ze gebruike kunnen worden. Of dat tijdens idle gebeurt of net voor het schrijven zal geen verschil uitmaken.

Voor de rest, ik snap niet dat het zo lang duurde om dit te verwezelijken. Het probleem was toch al lang duidelijk en de oplossing lijkt mij relatief simple. toch?

[Reactie gewijzigd door Chovav op 22 juli 2024 22:15]

[locke960]

Waarschijnlijk doen ze het nu pas omdat men in eerste instantie het gedrag van een reguliere harde schijf zo exact mogelijk wilde nadoen. Deze verandering heeft namelijk ook nadelen en risico's.

1. Als je op een gewone harde schijf per ongeluk een bestand verwijderd kun je dat meestal nog terug halen met een of ander "undelete" utility. Dit omdat het OS het bestand niet echt weggooit maar alleen de gebruikte ruimte als "beschikbaar" markeert. Zolang het OS er niet daadwerkelijk andere data overheen schrijft kun je de data terughalen.
Met deze firmware kan dat niet meer omdat de SSD zelf de vrij ruimte bij de eerste gelegenheid leeg veegt.

2. Dat de SSD dit zelfstandig kan betekent dat deze niet meer domweg doet wat het OS vraagt, de SSD moet daadwerkelijk begrijpen hoe het filesysteem in elkaar zit. dwz, als het OS in de index aangeeft dat de ruimte beschikbaar is moet de firmware zelfstandig bepalen welke blokken op de SSD gewist kunnen worden. Dat kan bij een beschadigt filesysteem extra problemen opleveren. Het is trouwens ook de vraag welke filesystemen er ondersteund worden. Ik heb alleen nog maar Windows test resultaten gezien.

@Goderic: Het trim commando is de logische oplossing, maar dat wordt nergens genoemd. Dit lijkt een work around om de perfomance op te krikken op systemen die het trim commando (nog) niet ondersteunen.

[Reactie gewijzigd door locke960 op 22 juli 2024 22:15]

[Goderic]

De SSD doet nogsteeds domweg wat het os vraagt: met het trim commando (wat btw ook in de nieuwste Linux kernel gaat zitten) zegt het os welke blokken nietmeer gebruikt zijn en de de SSD wist deze dan.

[twiFight]

Ik vind het inderdaad ook raar. Het eerder wissen van de 'lege' blokken was precies wat ik in mijn hoofd had, en ziedaar een paar regels later lees ik dat dat ook de 'fix' is. Overigens was mijn idee het gelijk bij het wissen van bestanden te doen, aangezien performance van de schijf er dan toch weinig toe doet. Ik heb zelden mijn HDD in gebruik wanneer ik iets wis.

Maar goed het zal wel komen door een nieuwe technologie, die fabrikanten zo snel mogelijk op de markt willen hebben.

[johnbetonschaar]

Het werkt net iets anders volgens mij. Wat ik ergens anders gelezen heb gaat het niet om het wissen van lege blokken, maar om het wissen van lege *cellen* van de SSD. Een SSD is opgebouwd uit cellen van (ik geloof) 512KB die opgedeeld zijn in blokken van 4KB. Op het moment dat een cel wordt beschreven waarvan bijvoorbeeld 320 van de 512KB bezet waren, dan wordt eerst de hele cel gelezen, gewist en dan herschreven met 512KB (de originele + de nieuwe inhoud).

Wat deze firmware update doet is een vorm van garbage collection, als de drive idle is loopt de controller alle niet volledig volle cellen af en bundelt de inhoud tot pakketjes van 512kb, zodat er meer volledig lege cellen overblijven. Writes van nieuwe data hoeven dan minder vaak half-volle cellen te legen/herschrijven op het moment dat de performance er wel toe doet.

De oplossing in deze firmware is dan dus ook net iets complexer dan het artikel doet vermoeden, want een efficient en veilig garbage collection algoritme schrijven is zeker niet triviaal.

[Reactie gewijzigd door johnbetonschaar op 22 juli 2024 22:15]

[ls470]

De uitleg klopt ongeveer, maar de terminologie is niet helemaal juist: een NAND chip is opgebouwd uit blokken (de kleinste wisbare eenheid) die overeenkomen met wat jij cellen noemt.
Die blokken zijn onderverdeeld in paginas (bv. 2kB of 4kB) die de kleinste schrijfbare eenheid zijn (soms kan een pagina gedeeltelijk beschreven worden, maar dit is zeer beperkt)
De cellen van het geheugen zijn individuele floating gate transistoren, en komen dus overeen met 1 bit per cel (SLC) of 2-3 bit per cel (MLC)...

Het opruimen moet natuurlijk alleen gebeuren met blokken die cellen/paginas bevatten die al beschreven zijn, maar geen zinnige data meer bevatten (zodat het volledige blok gewist moet worden om die weer klaar voor gebruik te maken), niet met blokken die voor een stuk echt leeg zijn (gewist maar nog niet geschreven)...

[DigiK-oz]

Gelijk bij het wissen van bestanden KAN ook. Enige vereisten : een SSD die het "trim" commando ondersteund (de meeste nog niet, maar wellicht ook via firmware toe te voegen) en een OS wat het ondersteund (weet alleen dat Windows 7 het doet, wellicht ook *nix varianten, eerdere windows versies in ieder geval niet).

Maar dan nog, is dit erasen tijdens idle time een hele mooie feature, al zal het met drives die kunnen trimmen plus windows7 dan niet/nauwelijks gebruikt worden.

[Superstoned]

Een aantal nix bestandssystemen ondersteund Trim al, laatste kernel zou het moeten doen. Verder hoop ik dat deze verbetering ook voor linux kan komen, maar ik vermoed dat er vieze dingen zoals een daemon nodig zijn...

[robvanwijk]

Ondersteuning voor TRIM is sowieso vereist; anders weet je niet welke blokken weer vrijgegeven zijn.
Er zijn drie soorten blokken: (1) nog nooit beschreven (2) ooit beschreven maar niet meer in gebruik (3) ooit beschreven en nog steeds in gebruik. Zonder TRIM kun je het verschil tussen de tweede en derde soort niet weten. En aangezien het nou juist precies de tweede soort is die je op wilt ruimen (en als het ware "terugzetten" naar de eerste soort) kun je zonder TRIM niks beginnen.

[Katsunami]

Ik vind het inderdaad ook raar. Het eerder wissen van de 'lege' blokken was precies wat ik in mijn hoofd had, en ziedaar een paar regels later lees ik dat dat ook de 'fix' is.

Eigenlijk vind ik het vreemd dat dit er nu pas is. Dingen optimaliseren tijdens idle-status is al zo oud als de tijd:

- Virusscan
- Defragmentatie
- Wachten met schrijven naar de hdd totdat deze even niet gebruikt wordt...
- ...

Toen ik voor de eerste keer las dat de blokken op SSD's eerst gewist moesten worden voordat er iets nieuws in kon worden geschreven, en dat dit het gebruik vertraagde naarmate er minder direct vrije blokken waren, was het eerste dat in mij opkwam: "Kunnen we defragmenteren in de achtergrond niet vervangen door wissen in de achtergrond?" En ziedaar...

Ik ga ervan uit dat men dit al lang in gedachte had, al sinds het eerste begin, maar dat nu pas het algoritme optimaal c.q. goed genoeg is.

[Marc H]

Fijn dat dit in de firmware komt.

Betekend dat het ook werkt voor raid systemen, en hoef je geen kunstgrepen meer uit te halen om je SSD's te trimmen. Ik zat te hopen op een driver voor de ich10r die een ingebouwde trim functie had, maar dit is natuurlijk nog mooier.

* Marc H heeft vier vertexen in Raid 0.

[Titusvh]

Maar moet die SSD nog steeds niet geattendeerd worden op het feit dat een blok leeg is?
Daar is volgens mij dat TRIM commando voor, wat nog niet in Vista zit.

Dus ik twijfel eigenlijk of we hier nu al wat aan hebben.

Ook ik zit te wachten op een oplossing om SSD in RAID te draaien. Maar als mijn performancewinst na twee weken al foetsie is doordat er geen vrij blokken meer zijn schiet dat niet op en kan ik ze net zo goed 'los' gebruiken. Dan kan ik met die cleaningtooltjes die de fabrikanten leveren tenminste makkelijk wekelijkse opschonmingen draaien.

[edit]
Bij nader nadenken weet de SSD soms wel degelijk welke blokken in aanmerking voor garbagecollection. Namelijk als een WIJZIGING wordt weggeschreven, en de SSD dit vanwege performance in een maagdelijk blok doet, dan weet de SSD welk blok ongeldig is.
Echter bij een delete wordt alleen in de metadata van het filesystem een vlaggetje gezet. Daarvoor hebben we dan nog steeds 'trim' nodig.

Dit brengt me ook op een ander punt: (minieme) wijzigingen in de metadata van het filesystem heb je al gauw. Het zou me verbazen als je niet heel gauw door je vrije blokken bent.
Zeker, maar niet alleen, omdat NTFS ook 'last accessed' bijhoudt, dus zelfs als je alleen leest.
Een slimme schrijfcache verzacht het leed misschien wat (bundelen van de updates). Maar gelukkig kan je dit 'last accessed' wel uitzetten.

[Reactie gewijzigd door Titusvh op 22 juli 2024 22:15]

[_Thanatos_]

Handig als je nog geen Windows 7 hebt. Maar als je die wel hebt, maakt het toch geen verschil?

[flamingworm]

nee, zelfs met Windows 7 werkte het TRIM commando nog niet, want de hardware ondersteunde het nog niet. Nu kan de hardware overweg met het TRIM commando. Je hebt dus enkel maar voordeel bij deze firmware als je Windows7 of een ander OS dat trimmen ondersteunt hebt, en je merkt helemaal geen verschil wanneer je XP/Vista zou draaien, want deze ondersteunen het TRIMMEN niet.

[Femme]

Carbage collection heeft niets te maken met trim. Garbage collection zorgt ervoor dat geheugenblokken die gedeeltelijk zijn gevuld met actieve data worden samengevoegd zodat er meer lege geheugenblokken ontstaan die snel beschreven kunnen worden. Halfgevulde geheugenblokken ontstaan als een gedeelte van de gegevens in het geheugenblok worden gewijzigd en de ssd-controller besluit om de wijzigingen in een ander geheugenblok met lege geheugenpages op te slaan omdat die sneller beschreven kunnen worden.

Het trim-commando voorziet in een methode voor het besturingssysteem om aan het opslagapparaat kenbaar te maken welke gegevens ongeldig zijn geworden. Het opslagapparaat kan vervolgens besluiten om zijn garbage collector ook los te laten op deze gegevens.

[_Thanatos_]

Sowieso heeft TRIM niks met hardware te maken. De geheugenchips hoeven alleen maar blokken data te lezen/schrijven/wissen. Het is de firmware die TRIM ondersteunt (of niet natuurlijk).

Maar zoals Femme al begrijpt, mijn opmerking ging over garbage collection. Als het OS dus TRIM netjes implementeert en de firmware dus ook, zou je naar mijn idee geen garbage collection nodig moeten hebben. Dat lijkt me alleen nuttig voor een OS die geen TRIM doet.

[Reactie gewijzigd door _Thanatos_ op 22 juli 2024 22:15]

[Verwijderd]

dat is heel mooie natuurlijk!

maar ik vraag me wel af, of dit invloed heeft op de levensduur van de ssd?

[Phyxion]

Of niks of het wordt er beter op (Ik denk het laatste). Of je ze nu meteen leegt haalt of later maakt niks uit voor de levensduur. Het voordeel van later doen is dat er niet te veel tegelijk gebeurd en waarschijnlijk voor een betere levensduur zorgt.

[ls470]

Het lijkt me logischer dat de levensduur hierdoor vermindert: stel dat bijvoorbeeld de helft van een blok verouderde data bevat. De controller gaat dan de andere helft van het blok moeten copieren naar een nieuw blok, zodat het oude blok gewist wordt en terug beschikbaar is.
Als daarna het nieuwe blok verder volgeschreven wordt en de tweede helft van wat in een oud blok stond gewist wordt moet de controller terug een half blok copieren om het te kunnen wissen en vrijmaken.

Anderzijds, als de controller wacht tot het echt nodig is om dat blok te wissen kan het zijn dat beide helften tegen dan al gewist zijn en dus niets naar een ander blok gecopieerd moet worden en dus maar in totaal 1 blok gewist wordt.


Het is dus niet zo simpel om de controller te laten beslissen wanneer hij mag/moet beginnen met opruimen in idle-time: te weinig en het heeft geen effect; te veel en de levensduur wordt serieus ingekort...

[Verwijderd]

Dat klopt niet helemaal, de blokken waar hier over gesproken wordt zijn de flash sectors, deze zijn meestal 512 bytes. Een bestandssysteem maakt ook gebruik van sectors, deze zijn altijd even groot of groter (bijvoorbeeld 2 kilobytes) dan deze flash sectors. Een sector is dus nooit "deels" beschreven: het maakt wel deel uit van een bestand of het maakt er geen deel van uit. Natuurlijk kan een bestand wel groeien (een log bijvoorbeeld), maar dat is geen probleem: Een gewiste sector kan wel deels beschreven worden en later aangevuld (bits kunnen maar één kant op "vallen" in flash, de andere kant moet de hele sector gewist worden).
Het enige wat er hier dus gebeurd is dat in plaats van deze volgorde:
write-use-delete-nothing-erase-write
wordt deze volgorde aangehouden:
write-use-delete-nothing-erase_while_nothing-nothing-write
Het enige nadeel, zoals hieronder beschreven, is dat files niet geundelete kunnen worden.

[springtouwtje]

een Flash sector is van buiten misschein 512 byte, maar de page size van een page erase is meestal veel groter.

[Vastloper]

Je begrijpt het artikel niet helemaal, het is geen defragmentatie process dat is sowieso af te raden op SSD omdat dit altijd je schijven eerder door de cycles laat gaan. Dit gaat puur om een erase cycle uitvoeren op blokken die volledig zijn vrijgegeven al, normaal als je iets wist in een filesysteem dan word de data zelf niet gewist maar de de entry in de filesystem tabel die verwijst naar het blok word geleegd, zodra iemand anders het blok kan gebruiken voor een nieuw bestand oid dan word er een nieuwe entry gezet en het blok direct overschreven.
Bij de normale schijven van vroeger was een erase zinloos en was het sneller direct de nieuwe waarden erin te schrijven zodra dit kon. Bij SSD en met name flash chips moet een page/block eerst gewist worden voordat je gaat shcrijven. Met schrijven van flash kan je namelijk alleen 1'en 0 maken. een erase cycle zorgt ervoor dat een heel block/page in 1 keer weer naar alleen 1'en word gezet.
Nu is de truuc dus om tijdens idle alles alvast te erasen wat al is vrijgegeven zodat er in 1 keer "overschreven" kan worden. Nadeel hiervan is echter wel dat het programma's als undelete onmogelijk maakt. Wel een voordeel voor gevoelige gegevens.

[siggie]

Blocks moeten toch eerst gewist worden eer dat deze weer beschreven kunnen worden. Wat er nu gebeurd is dat het wissen van vrijgegeven blokken veel eerder gebeurd, zodat wanneer deze blokken weer gebruikt gaan worden, direct de schrijfactie kan plaatsvinden (ipv wissen+schrijven).

[]Byte[]

Volgens mij niet. Het verschil is dat het wissen van de eerder beschreven blokken nu in idle-tijd gedaan worden en niet op het moment dat het geheugenblok opnieuw beschreven word. (zoals nu gedaan word)
Dat scheelt dus de wis-actie voordat de schrijfactie gedaan kan worden.
Simpel maar effectief!

[Reactie gewijzigd door ]Byte[ op 22 juli 2024 22:15]

[Verwijderd]

je bedoelt van 171 jaar naar 169 jaar bv ?

[Verwijderd]

Inderdaad. Steeds weer opnieuw die discussie over de levensduur van flash. Ze hebben een langere levensduur dan klassieke harddisks met bewegende onderdelen!

[VNA9216]

Maar gaat die controller nu niet veel meer stroom verbruiken omdat hij eigenlijk continu bezig zal zijn?

[LvdBlom]

Volgens mij is dat maar van korte duur. Immers, er zal een moment zijn waarbij alle vrije blokken geleegd zijn, zodat er niks meer te legen valt, en dan zal de SSD drive alleen maar in idle toestand blijven en weinig stroom verbruiken.

De mate waarin de SSD in idle toestand zijn opschoonwerk doet, hangt af van hoeveel operaties er geweest zijn na de laatste succesvolle poging tot opschoning, zodat het de ene keer van korte duur is en de andere keer van lange duur, maar het extra stroomverbruik is sowieso tijdelijk.

Het is echter een wilde gok. Ik heb er zelf ook niet veel verstand van, maar het lijkt me wel logisch.

[VNA9216]

Maar hij moet immers ook regelmatig checken of er blokken gewist moeten worden.
Zolang ze dat niet overdrijven valt het denk ik idd wel mee, maar je wilt dus duidelijk niet veel tijdelijke bestanden schrijven en weer weggooien denk ik. (al wil je dat natuurlijk altijd beperken met een SSD

[flamingworm]

Zo zal er wss ingesteld kunnen worden dat wanneer een notebook/laptop/netbook op batterij bezig is de SSD niet getrimmed wordt, net zoals nu er dan niet gedefragmenteerd of geïndexeerd wordt. Vermoed ik
Of wie weet kun je het wel helemaal uitschakelen in 1x in de week/maand "trimmen"

[D2D_Christiaan]

ja vast wel iets meer. maar het maximale verbruik van een SSD (onder load dus, bij de vertex +- 1W) is nog minder dan de meeste HDD in idle (meestal iets van 5 a 8W).

[springtouwtje]

wat in het OS opgelost mote worden, is dat het opschonen van de SSD alleen gebeurt als de laptop mains powered is.

[joco]

hoe weet de ssd eigenlijk wat hij kan deleten?
Ben je daar niet net het trim commando voor nodig?

Want als ik free space op vraag dan weet het filesysteem toch exact wat vrij is. Maar weet de hardware (sdd) dat eigenlijk wel?

[joppybt]

Wat ik begrijp: als een SSD een bestaande sector moet overschrijven van het operating systeem dan zal hij daar intern bij voorkeur een nieuw, vrij, leeg blok voor kiezen. Het operating systeem merkt dat helemaal niet maar ondertussen wordt intern in de SSD het oude blok wel gemarkeerd als 'vrij'. Op deze manier kunnen er toch lege blokken ontstaan.
Als je in het OS (zonder TRIM) een bestand weggooit dan heeft de SSD dat nooit door en kan hij daar niets 'leuks' mee doen (vroegtijdig wissen).

Intrigerende vraag: stel je schrijft vanuit het OS (zonder TRIM) een keer je hele SSD vol en verwijdert alle bestanden weer. Kan de nieuwe garbage collector dan nog iets zinvols bijdragen?

[SgtCaffran]

Deze nieuwe firmware is gelijk aan 1.30 volgens een eerder vermelde review met als enige wijziging de garbage collect en het ontbreken van support van het TRIM command.

De garbage collect werkt dus zonder TRIM!

[Titusvh]

Voor een delete wel. Maar bij een wijziging doet de SSD toch een schrijfactie naar een leeg blok. Maar bekend is welk blok hij had moeten updaten. Die kan hij nu als vrij markeren.

[joppybt]

'Gewoon' overschijven is er niet bij bij een SSD. Daar kun je heel gemakkelijk een cel van '0' naar '1' zetten maar omgekeerd is veel ingewikkelder: dat kan alleen door eerst een heel blok te wissen.
Vergelijk het met een blanco vel papier: met een scherp potlood kun je heel nauwkeurige lijntjes tekenen (van '0' naar '1') maar heel nauwkeurig een lijntje wissen kan niet omdat gum 'grof' werkt. Dan ben je beter af een groter gebied eerst uit te gummen en de stukken die je wilt behouden opnieuw te tekenen.

[Admiral Freebee]

Bovendien bevat één geheugencel bij MLC (Multi-Level Cell) meer dan één bit informatie. Als dus maar één bit van deze cel veranderd moet worden, moet heel de cel gewist worden, en terug beschreven met de juiste informatie.

[ASS-Ware]

'Gewoon' overschijven is er niet bij bij een SSD. Daar kun je heel gemakkelijk een cel van '0' naar '1' zetten maar omgekeerd is veel ingewikkelder: dat kan alleen door eerst een heel blok te wissen.

Interessant.
Maar hoe zit dat dan met databases ?
Die delete je niet, je wijzigt alleen de data in het bestand.
Of een permanente swapfile, die je op 1 vaste locatie laat staan.