Samsung 850 Evo långsam knappt använd på flera år

Alla TLC (och QLC)-baserade SSD/NVMe blir slöa när de inte används eller har varit avstängda och varit strömlösa i längre tider - spelar ingen roll om det är Intel, Kingston, Samsung, Sandisk, Hynix och alla noname som finns.

Hanterar emellanåt en del SSD och även mot NVMe på jobbet och det är en pina att skicka tillbaka en ny diskimage med uppdaterade program på SSD och NVMe som har legat ett tag... man är inte överdrivet imponerad av SSD/NVMe efter en tid med dessa bulkskrivningar då det går bara fort precis i början av skrivningarna medans resten av skrivningen kunde göras fortare på en 2.5" laptopsnurrdisk - jag skojar inte, när man är nere på 40-50 MB/s i sekventiell skrivning mot en SSD/NVMe så inser man att det går fortare att skriva diskimagen på en modernare SATA-laptop-snurrdisk (som toppar över 110 MB/s) då det är i stort sett bara sekventiell skrivning från början till slut...

En del SSD/NVMe repar sig i hastighet om man läser hela volymen från börja till slut ett flertal gånger och dess logik inser att en del flash-block läses oerhört långsamt eller att det är extensiv användning av olika ECC-mekanismer innan rätt data har lästs ut. - det verkar också att man faktisk måste läsa blocken innan de skrivs om, om de är för långsamma - att bara strömsätta dessa innebär inte att de automatiskt tränas om för högre läshastighet eller att det tar väldigt tid innan de gör det - detta är typiskt saker i firmware som är dåligt uttestat och i många fall inte fungerar när det faktiskt behövs eftersom ingen tillverkare är villiga att vänta i 2 år på att se att sådant fungerar som det skall...

Senast testade jag på en dator som inte hade anslutits sedan flytt för drygt 1.5 år sedan, är att först efter den 3-4' fulla läsningen av en Samsung 840 EVO som det börja bli sprutt i dessa - dvs. över 300 MB/s (diskdockan klarade inte högre) och i mitt fall så startade det med 0.5 MB/s i den första läsningen efter att har varit strömlös i drygt 1.5 år - det räckte i det här fallet bara att läsa enheten upprepande (med typiskt 'dd if=/dev/sda of=/dev/null bs=10240k status=progress' i Linux). Det behövde inte skriva något på SSD:n för att återväcka den till bra hastighet och den läste också ut all data felfritt - utan IO-error - det gör inte alla SSD:er som har legat längre tider.

Här skiljer det också hur bra denna ECC är mellan olika modeller och fabrikat. Samsung skulle jag säga har väldigt bra felrättning med en mjukvaru-ECC ovanpå det som fins på själva flash-chippen, medans Sandisk får man IO-fel och det hänger sig hårt och krävde spänning av/på igen innan den syntes igen och förblev så med hängning igen när sagda sektor skulle läsas igen tills det skrevs över med ny data (11 månader i skrivbordslådan räckte i mitt fall) och det är olika nivåer på felrättningsförmåga och hur de beter sig om data inte går att läsa mellan märken och modellserier.

Att skriva och sedan radera på den lediga utrymmet kommer också att snabba upp framtida skrivningar på SSD/NVMe som legat till sig. Det bästa om man kan göra 'TRIM'/discard på all ledig utrymme (i Linux gör man det med 'fstrim') och tala om för diskkontrollerna att dessa minnesareor används inte längre och därmed kan kontrollen göra erase på dessa block - annars kan det ta väldigt tid att skriva ny data då gammal data på de LBA-adresser man precis tänker skriva över, skall hela tiden läsas in och ev. flyttas om till nya flashblock (alltså de blocken som inte har skrivorder på sig just då, även om de 64-1024 kbyte senare får en skrivorder - men det inser inte kontrollern just då... - framförhållning i skrivning på SATA-SSD kan vara så lite som 64 kByte-block av historiska orsaker i SATA-protokollet) - tex. TRIM-kommandon skickas ofta som en rad med block på max 64 kByte per 'order' till SSD:n och det fins begränsning i hur många sådana block man kan skicka i en batch innan det blir problem...

tex. när man i windows radera en väldigt stor fil på SSD/NVMe - så skickas det under en ganska lång tid TRIM-kommandon för sektorerna för filen i små portioner, dels för att inte få problem med buggiga SSD som inte kan ta för många sådana kommandon i kö på en gång, men också att i SATA-SSD så fryser disken var gång en TRIM-kommando körs (den blockerar IO-access när TRIM exekveras i SSD:n) och skickar man för många paket på en gång så kan hela OS frysa och hacka i väntan på att SSD skall svara igen medans TRIM körs på SSD:n - så, man smetar ut processen över tiden i små, små block så att hackandet/stutter inte blir så märkbar. I NVMe så är det definierat att lagringen inte skall frysa under en TRIM-kommando - av förekommen anledning från SATA-SSD...