omgekeerde defrag en SSD

[boner]

Hallo,
een disk optimalisatie schrijft altijd alle data zo veel mogelijk naar de eerste sectoren van een harddisk. En daarnaast schrijft het ook alle data in één lange file zonder dat de files in stukjes zijn gefragmenteerd.

Bij een SSD is dat beide niet nodig. Headtravel is 0 en dus is het niet verstandig om toe te passen op een SSD. Het is zelfs slecht omdat je heel veel reads en writes doet terwijl het aantal cycles van een SSD juist beperkt zijn tov een spinning disk.

Echter zit er in mijn laptop een SSD. 50% van de ruimte is 'vrij' en 50% is bezet met relatief onveranderlijke data. Ik denk dat dat bij vrijwel iedereen zo zal zijn. WIndows en de programma's zijn vele malen groter dan de 'normale' bestanden die je maakt. Afgezien van video's natuurlijk.

Nu zegt de SMART info van de SSD dat de betrouwbaarheid van de disk 'GOOD' is. Maar na verloop van tijd zal de vrije ruimte veel read/write cycles mee hebben gemaakt en gaat de 'GOOD' kwalificatie achteruit (geen idee hoe het dat genoemd gaat worden maar is miner belangrijk). Echter zijn de cellen waar het OS en Applicaties op staan niet vaak herschreven. iig niet in de buurt van wat het einde van de betrouwbaarheid betreft.

Het zou daarom wel handig zijn als er een utility is die de stabiele files verplaatst van zelden herschreven cellen naar vaak beschreven cellen. Op die oude plek kun je dan weer veel cycles aan en is de levensduur van de SSD verlengt.

PS: ik heb de swapfile uitgezet, dus die enorme hoeveelheid writes is al een heel stuk minder. 16G kost zo weinig dat het zekers de moeite waard was.
Weet iemand of er zo een utility is?

PS2. als de mod's een betere naam voor dit onderwerp weten graag. Ik weet het niet maar noem het zo omdat de truuk veel weg heeft van techniek die defrag gebruikt namelijk het herschikken van sectoren.

[Verwijderd]

Volgens mij heet dat gewoon TRIM?

Edit: nog even snel gegoogled en ik heb toch niet helemaal gelijk. Maar er zijn wel technieken als TRIM en garbage collection die verval van de SSD voorkomen. Overigens was er laatst wel een issue met Samsung SSD's die met data die te lang op dezelfde plek stond significant langzamer werden. Dit kwam omdat de niveaus van de voltages van die data te snel omlaag ging en daarom de error correction behoorlijk zijn best moest doen.

[ Voor 86% gewijzigd door Verwijderd op 17-02-2015 12:00 ]

[mcDavid]

Dat heet wear leveling en dat doen alle SSD's van zo'n beetje na 2010 gewoon automatisch.

[TERW_DAN]

Bij mijn weten is dit inderdaad wat TRIM doet, iets dat automatisch gebeurd zodat de cellen evenredig beschreven worden. Dat gaat automatisch, dus daar hoef je zelf niet veel aan te doen.

[mcDavid]

Niet helemaal. Trim is het opschonen van ongebruikte data. Direct gevolg daarvan is wel dat de daardoor vrijgekomen blocks weer gebruikt kunnen worden door het wear leveling algoritme.

[borft]

TRIM zorgt er volgens mij voor, dat verwijderde blokken weer vrij gegeven worden. Het werkt alleen als disk, controller en filesystem het ondersteunen.

Wat OP bedoelt, is volgens my was mcDavid ook zegt, wear leveling. Dit zorgt ervoor dat writes eerlijk verdeeld worden, zodat alle cellen gelijkmatig slijten.

[Bor]

Wear leveling is wat je zoekt volgens mij. Dat heb je in verschillende manieren waaronder dynamic en static.

Meer info: Wikipedia: Wear leveling

[Weemism]

Maar wat de TS vraagt is dus niet nodig, wear levelling is tegenwoordig een standaard functionaliteit van de controller, hier hoef je zelf dus niets aan te doen, en geen aparte programma's voor te installeren.

Wear leveling is a fact of life with NAND flash – blocks start to suffer bit failures after a certain number of erase/write cycles (usually specified from the thousands to the hundreds of thousands) and it is only natural that software will attempt to over-write some blocks more than others. In order to prevent this from causing failures, all of today’s SSD, USB flash drive, and flash card controllers incorporate some sort of wear leveling.

Interessant artikel daarover hier.

[boner]

Wat ik lees bij wear leveling is dat de vrije ruimte zo wordt gebruikt dat de wear op DIE cellen verdeeld wordt. Wat ik zoek is een prog die de beschreven cellen meeneemt in het truukje. Dus eens in de zoveel tijd, maanden, de volle cellen over de lege cellen schrijven en de oude (vroeger volle maar nu vrijgekomen) gaat gebruiken en de wear leveling op kan toepassen.

*edit* hier staat het wel goed. Dus niet noodzakelijk!

Static wear leveling manages write leveling across all of the flash in the system – the changed blocks, the unused blocks, and the static blocks. This means that a static block that contains valid data but that is never being written to will still be moved around within the flash in order to allow all blocks to receive the same amount of wear. It’s easy to understand why this would help, since those blocks would otherwise be unavailable to the wear leveling algorithm. On the other hand, if you’re trying to minimize write/erase cycles, it’s unintuitive that this approach is the better of the two.

[ Voor 48% gewijzigd door boner op 17-02-2015 12:21 ]

[Thralas]

De SSD controller weet wat hij doet. Proberen 'm slimmer af te zijn is waarschijnlijk zonde van je tijd.

[Rannasha]

boner schreef op dinsdag 17 februari 2015 @ 12:18:
Wat ik lees bij wear leveling is dat de vrije ruimte zo wordt gebruikt dat de wear op DIE cellen verdeeld wordt. Wat ik zoek is een prog die de beschreven cellen meeneemt in het truukje. Dus eens in de zoveel tijd, maanden, de volle cellen over de lege cellen schrijven en de oude (vroeger volle maar nu vrijgekomen) gaat gebruiken en de wear leveling op kan toepassen.

Dat gebeurt al.

Moderne wear leveling algoritmes in SSDs zullen periodiek statische data verplaatsen naar "actieve" sectoren, zodat sectoren waar lange tijd niets mee is gebeurd vrij komen voor nieuwe schrijfacties.

Dit heet "static wearleveling" (static omdat ook statische blocks worden meegenomen) in tegenstelling tot "dynamic wearleveling", waar enkel dynamische sectoren (dwz: regelmatig wijzigend) profijt hebben van de wear leveling.

[begintmeta]

Rannasha schreef op dinsdag 17 februari 2015 @ 12:21:
[...]


Dat gebeurt al.

Moderne wear leveling algoritmes in SSDs zullen periodiek statische data verplaatsen naar "actieve" sectoren, zodat sectoren waar lange tijd niets mee is gebeurd vrij komen voor nieuwe schrijfacties.

Dit heet "static wearleveling" (static omdat ook statische blocks worden meegenomen) in tegenstelling tot "dynamic wearleveling", waar enkel dynamische sectoren (dwz: regelmatig wijzigend) profijt hebben van de wear leveling.

Inderdaad

[mcDavid]

boner schreef op dinsdag 17 februari 2015 @ 12:18:
Wat ik lees bij wear leveling is dat de vrije ruimte zo wordt gebruikt dat de wear op DIE cellen verdeeld wordt. Wat ik zoek is een prog die de beschreven cellen meeneemt in het truukje. Dus eens in de zoveel tijd, maanden, de volle cellen over de lege cellen schrijven en de oude (vroeger volle maar nu vrijgekomen) gaat gebruiken en de wear leveling op kan toepassen.

Dat zou nogal onzinnig zijn. Als je dat geforceerd zou doen levert het alleen maar een heleboel onnodige writes op. Je mag er gerust van uit gaan dat in de tig jaren dat je je SSD gebruikt, ieder block wel een keer een schrijfactie te verwerken krijgt. Die schrijfactie wordt dan door de controller aangegrepen om dat block te verplaatsen.

Thralas schreef op dinsdag 17 februari 2015 @ 12:21:
De SSD controller weet wat hij doet. Proberen 'm slimmer af te zijn is waarschijnlijk zonde van je tijd.

Dit is eigenlijk wel de belangrijkste samenvatting ja. Daaraan toegevoegd dat het niet alleen zonde van je tijd is maar ook nog eens contraproductief kan zijn.

[ Voor 18% gewijzigd door mcDavid op 17-02-2015 12:27 ]

[Reepje]

mcDavid schreef op dinsdag 17 februari 2015 @ 12:23:
[...]


Dat zou nogal onzinnig zijn.

En toch gebeurd dit.
Daarom ook dat als je kijkt naar het aantal geschreven GB (door jouwzelf) en het aantal werkelijk geschreven GB een factor 2 tot 3 hoger kan liggen (dit heet weer: write amplification). Dat komt omdat wear levelling bestaande bestanden verplaatst.

[ Voor 4% gewijzigd door Reepje op 17-02-2015 12:40 ]

[mcDavid]

Reepje schreef op dinsdag 17 februari 2015 @ 12:35:
[...]


En toch gebeurd dit.
Daarom ook dat als je kijkt naar het aantal geschreven GB (door jouwzelf) en het aantal werkelijk geschreven GB een factor 2 tot 3 hoger kan liggen. Dat komt omdat wear levelling bestaande bestanden verplaatst.

Volgens mij komt dat vooral doordat blocks vaak groter zijn dan de data die je schrijft, zeker als het om kleine bestandjes gaat. Overigens kan daar wel weer gebruik van gemaakt worden, als er statische en dynamische data in één block zit, kan de controller die statische data mooi verplaatsen bij een write van de dynamische data zonder dat het extra writes kost.
Ik ben geen SSD-controller expert of zo maar het lijkt me toch dat het geforceerd verplaatsen van statische data zelden nodig zal zijn, en als het dat wel is, dat het tot een absoluut minimum beperkt wordt.

[borft]

Volgens mij is dat ook waar wear leveling en trim elkaar raken. Een ssd kan geen updates aan blocks doen, wat er onderwater gebeurt, is dat bij een update het huidige block als deleted gemarkeerd wordt, en de updated data in een nieuw block geschreven wordt. Hierbij zorg de controller ervoor dat blocks ongeveer even vaak geschreven worden. TRIM zorgt ervoor dat blocken die in je filesystem als deleted gemarkeerd worden, door de disk controller weer als vrij worden gemarkeerd, zodat ze weer beschikbaar zijn voor writes.

[Reepje]

mcDavid schreef op dinsdag 17 februari 2015 @ 12:42:
[...]

Volgens mij komt dat vooral doordat blocks vaak groter zijn dan de data die je schrijft,

Dat ook.

Waar het hier om gaat is, dat door wear levelling ook hoeveelheden data moet worden verplaatst. Het zou best wel eens kunnen dat bijv de oude Samsung840evo een te voorzichtige controller had waardoor oude data wel op zijn oude plaats bleef staan. En dat was dus ook fout. Vandaar een nieuwe firmware die dit zou oplossen. De manier waarop ze dit nu wel voorelkaar krijgen, lijkt mij dat data eerder verplaatst wordt.

Als het goed is zal wear leveling oude data om de zoveel tijd een nieuw plekje geven. Blijft het op dezelfde plek staan, gaat immers de integriteit van de data langzaam verloren.

[jan99999]

In je bios instellen, tav je harde schijf controller, AHCI(en dan windows installeren).
Edit: Dan heb je met een ssd ook TRIM.(dit is dus fout).
AHCI heeft blijkbaar niks met trim te maken, maar wel dat je communicatie van je controller vlugger kan gaan met AHCI ipv ide.

En voor de rest hoef je niks te doen, ook je swap uitzetten of verplaatsen in niet meer nodig, je verliest snelheid, wat je juist wilt hebben.
En ssd's kunnen tegenwoordig heel veel hebben, zo snel gaan ze niet defect.

[ Voor 17% gewijzigd door jan99999 op 18-02-2015 09:28 ]

[Swordlord]

Veel goede punten, je probeert fabels te ontkrachten. Alleen dat per se ahci nodig is voor trim is ook een fabeltje

[SMSfreakie]

maar als je AHCI kan gebruiken moet je het wel doen