Detta är nog ett problem som alla SSD har mer eller mindre uttalat och döljs olika väl med firmware.
Om detta med långsamma SSD har säkert alla läst, men att det kunde vara så 'illa' - det trodde jag inte.
Jag tar ibland ta en diskimage på mina Datorers SSD och kasta in dessa i en borgbackup, vilket gör att man kan ha flera generationer diskimage-backuper utan att arkiven sväller allt för mycket per ny image - trots allt så är stora delen av innehållet ganska lika mellan gångerna. Kör man cclear, bleachbit samt nollar allt ledigt utrymme (kan göras i bleachbit) innan diskimagen tas så blir man av med mycket av gamla (raderade) krypterade filer mm. från många av dagens applikationer som sprider runt dessa som gödselspridare kring sig och som annars tar plats och är unika även i borgarkivet.
I det här fallet så gäller det en Samung EVO840 250GB med knappt 30000 timmars drift, 28 TB skriven mängd och startad ca 100 ggr. kort sagt den har varit påslagen dygnet runt hela tiden mer eller mindre.
- Det har varit problem med hastigheten på SSD-diskmodellen ifråga om man läser runt lite, och det har till slut kommit firmware som skall fixa det mesta av det - och även denna disk har blivit uppdaterad med denna firmware för ca halvår sedan och enligt dess egna program så har den förväntad fart (datorn ifråga har bara SATA2, dvs. SATA-bussen klarar knappt 300 MB/s) och blev betydligt snabbare än innan uppdateringen, så något fixades till helt klart.
---
När jag i Linux läste av innehållet med 'dd' i en diskdocka så gick det trögt, ca 70 MB/s och dessutom hoppade det med högre och lägre hastighet ibland - så WTF... problem med diskdockan ??? - provade annan SSD-disk - 270 MB/s - och det är förmodligen dockan som begränsar i det fallet.
Tillbaka igen och börja läsa ut igen... men vad i H***, det går ju långsammare än en rätt medioker laptop-surrdisk ju....
hur eller hur, typ 1 timme senare så var det klart (mot förväntade 17 minuter för backuppen)
Såg till att image-kopian duplicerades till annan media... ....i fall att, för nu tänkte jag skriva över denna SSD med '0' för att se hur fort det egentligen gick. Sagt och gjort, efter en tjurrusning vid ca >200 MB/s det gick ned i imponerande hastigheten av 35 MB/s efter några få GB skrivet (Ca 5 GB) - men va i**** - det går ju fortare att bränna data på en bluray-skiva ju!!!!
Avbröt vänta lite (SSD:n blev ganska varm...) sedan provade jag och skrev från början igen (sektor 0 och framåt) nu gick det fort betydligt längre tid, därefter ganska hackigt ca 5 GB efter punkten jag bröt första gången och därefter tillbaka till 35 MB/s.
hmm - det är inte så att denna komprimerar nu när jag matar på med nollor???
OK, starta om datorn till windows - tänkte att om jag nu skrev psedoslumptal av det typen som vera/truecrypt ger (att gå via /dev/urandom och /dev/random i linux går inte fort...), så går det inte att komprimera och vera/truecrypt medger möjlighet att skriva direkt till en disk som arkivvolym även under windows.
Sagt och gjort och drog igång händelsehanterare för att följa diskbelastning, samma historia som tidigare, det gick snabbt över 200MB/s
en kort stund, skakigt och därefter ned till 35 MB/s med ibland djupdyk till under 20 MB/s - noterade samtidigt att den biten jag skrivit över tidigare verka skrivas över snabbt och när man kom förbi den punkten där jag tidigare bröt överföringen så sjönk hastigheten för att stabilisera sig vid 35 MB/s när man var va 5 GB förbi den punkten.
Nu resonerade jag att nu skriver jag disken fullt med slumptal och den vägen tvingar SSD att skriva om varenda flash-block på disken (förutom en liten del som är gömd och inte kommer åt direkt) - det tog åter igen en rejäl stund då det låg på ca 35 MB/s - flera timmar innan det var klart.
Nu var frågan - vad händer när jag skriver över igen med annan slumptal från vera/truecrypt-programmet - kommer det gå fort i början och långsamt resten då också...
Provade - svaret, nej, den höll faktiskt farten ca 200 MB/s skrivning hela disken igenom - lite skakigt var det på sina håll men klart över 200 MB/s i genomsnitt, provade en gång till - de fartmässigt skakiga partierna var nästan helt borta nu och medelhastigheten ytterligare lite högre!. OBS! dessa tester kostar Flash-slitage! - detta skall man vara medveten om!!
---
Gick tillbaka till linux och med 'dd' körde jag tillbaka imagen, och här var det gigabit-ethernet som begränsade vid ca 100 MB/s - det var inga 35 MB/s begränsning här nu - och vid läsprov efter så låg jag över 280 MB/s genom hela SSD genom diskdockan och det var förmodligen dockan som ströp farten och inte disken.
---
Det ser alltså ut som att skall man behålla full fart skriv och läs på Samsung EVO 840 - så måste den 'masseras' då och då med massiva mängder skrivning över disken, över hela dess diskyta - av tidigare observation med avbrutna skrivningar så verkar det handla om upp-plogning bokstavligen - dvs. man måste skriva på dom sektorer som man vill att de skall gå snabbare senare. - dvs. att skriva upprepande på sista 1/3-delen av disken gör inte den första 1/3-delen snabbare med intern reallokering av flashminne - dock har jag inte provat detta konstruktivt nog för att kunna säga det säkert...
---
Jag anar vad som händer - flashminnena läcker laddning med tiden vilket innebär att spänningsnivåerna som de programmerades med, glider (ned) sakta i spänning (på TLC-celler så är det 8 nivåer för 3 bitar) och börja närma sig nästa bitsnivåvärde, när man läser av det, med skala och offset-kompensering och liknande trix som man provar med allra först, så ger det tveksamma mellanvärde (typ spänningvärde för 3.5, inte 3 eller 4) och följden av dessa osäkra mellanvärden ger att bitfel läses ut (vilket upptäcks av CRC/ECC-systemet) - vilket gör att bitmönstren som läses ur går igenom faltningskodare typ viterbi-dekoder (som i princip bygger på en implementation av trellis-kod för att bedöma 'suddiga' värden) för att öka signal över brus/störnings-förhållandet och detta kan itereras i flera varv för att få lite bättre S/N-per varv med avtagande förbättringsgrad, och det snurrar tills ECC/CRC säger att dataströmmen har så lite fel att ECC-systemet ovanför kan felrätta de sista felen och datat levereras.
Detta kostar dock tid, ett enda varv med viterbi och idag numera LDPC-decoder kan halvera läshastigheten - gör den 4 varv per lyckad läsning så är man förmodligen under 100 MB/s på en 500 MB/s enhet.
Min låg på 35 MB/s och viterbi/LDCP-iterering är kanske både 6 och 8 varv - vilket börja bli nära den gränsen (ca 15 varv) att förbättringen uteblir med fler iterering av viterbi/LDCP-avkodarna.
Något säger mig att garbage-collektorn i SSD går runt och provläser cellerna vid ledig tid i sakta mak men gör ingen åtgärd innan antalet viterbi/LDPC-itereringar är på ganska stort belopp innan cellen programmeras om - givetvis för att minimera (dolda) slitaget på Nand-Flash minnena, men bekostnad på läshastighet (och indirekt påverkar skrivhastighet då det ingår att läsa innan man skriver när man möblerar om och har gjort slut på den gömda bufferten med redan raderade celler, vilket i det här fallet verka ligga runt 5 GB)
Just den här SSD har garanterat haft ström på sig 99% av tiden, det jag inte vet är hur gamla innehållet i cellerna som nu tvingades skrivas om, om det är 3 år gammalt sedan disken skrevs med data första gången eller om det är mindre än 6 månader, den låga läshastigheten var dock ganska jämn över större delen av disken (trots att jag skrev 60 GB med nollor på ledigt utrymme innan diskimagen - kan var komprimering inblandat där) och det har åkt in och ur data motsvarande 120 fulla skrivningar på disken under dessa 3 år och jag tror inte att vi har celler som har varit orörda sedan 3 år tillbaka - med andra ord den här laddningsdegraderingen går ganska fort efter en skrivning och läshastigheten går ned.
---
Detta att det är väldigt mycket 'bitfel' på rådata från en Flash-cell eller en HD-magnethuvud är helt normalt idag, det kan vara så hög feltakt på rådatat att det är 1 fel per 10 bitar avläst vid fullt normal drift på en HD, med viterbi/LDPC avkodning i avsikt att förbättra S/N kan man förbättra feltakten till 1 fel per 10000 bitar (ganska vanlig felsannolikhet på äldre magnetband och optisk media när de är i slutet av sin livslängd innan felrättning) och då börja den ordinarie övergripande ECC-hanteringet gripa in och rätta det som är kvar i felväg.
En 1TB hårddisk har ungefär 93 GB med felrättningsinformation inflätat för att Reed solomo/LDPC-felrättningen skall kunna arbeta korrekt.