Statische data herschrijven op een SSD

[aawe mwan]

Wat ik merk is dat als data langere tijd op je SSD staat en je er pakweg 4 jaar of langer niets meer aan veranderd hebt, dat het teruglezen van die data dan veel langzamer is (half zo snel of nog minder). Je kunt dit weer „snel” krijgen, door het bestand in kwestie een keer opnieuw naar de SSD te schrijven.

In mijn history kan ik terugvinden wat ik daar bijvoorbeeld voor gebruikt heb:

# Eerste 10 GB van /dev/sdb herschrijven (want dat stuk was het langzaamst)
dd if=/dev/sdb of=/dev/sdb bs=1G count=10

# emmc heeft ook last van dit probleem
sudo dd if=/dev/mmcblk1 of=/dev/mmcblk1 status=progress

Ik herschrijf dus alle blokken van de hele drive. Elke drive waar ik dit op gedaan heb was daarna te lezen met een veel hogere gemiddelde snelheid en ook een apt-get update/upgrade was weer lekker snel. Dit heeft dus het gewenste effect, toch heb ik een paar bedenkingen, waar jullie misschien tips/ideeën voor hebben:

• Liever zou ik alleen blokken herschrijven die daadwerkelijk voor een bestand in gebruik zijn. En dan dus ook alleen voor bestanden die al een paar jaar niet meer gemodificeerd zijn. Kan dat?
• Door het grote aantal schrijfacties wordt de drive vrij warm als je hem helemaal herschrijft, daarom zou ik het schrijven liever doen met beperkte bandbreedte. Nu gebruik ik ^Z + fg om het kopiëren te pauzeren tot de drive is afgekoeld. Bij pv heb je bijvoorbeeld de mogelijkheid om de doorvoersnelheid te verlagen. Kan dd dat zelf ook?
• Heb ik kans op datacorruptie doordat een ander programma een blok op de SSD verandert precies tussen het moment dat dd deze in het geheugen gelezen heeft en het blok terugschrijft? Of lockt hij dit zelf? Helpt het om de buffer van dd zo klein mogelijk te maken?

[swhnld]

Je loopt altijd een risico bij herschrijven van data op een SSD. En als je die data zo weinig gebruikt, waarom dat risico nemen?
Beter zorg je dat je indexen beter zijn, want dat is waarschijnlijk de oorzaak van je probleem, de indexen zien dat het weinig gebruikt wordt dus optimaliseren recent gebruikte data.

[aawe mwan]

swhnld schreef op zondag 31 juli 2022 @ 15:12:
Je loopt altijd een risico bij herschrijven van data op een SSD. En als je die data zo weinig gebruikt, waarom dat risico nemen?

In de loop van de jaren zakt de lading van een cel in een NAND geheugenchip een beetje weg. Nieuwe data is gemakkelijk terug te lezen, maar om oudere data te kunnen lezen bestaat de kans dat de SSD hem met aangepaste TLC/QLC levels moet decoderen en om dat te kunnen doen moet hij de NAND chip nog een keer uitlezen. Bij oudere data moet hij dit zelfs meerdere keren herhalen en dat ga je merken als „traag lezen”, tot het uiteindelijk helemaal niet meer lukt om het blok data betrouwbaar te decoderen (of je krijgt corrupte data die door puur toeval voldoet aan de check). Dat wil ik voorkomen door de cellen eerder te herschrijven.

Beter zorg je dat je indexen beter zijn, want dat is waarschijnlijk de oorzaak van je probleem, de indexen zien dat het weinig gebruikt wordt dus optimaliseren recent gebruikte data.

Wat zijn dit voor „indexen” waar je het over hebt en hoe kan je die beïnvloeden (welk commando doet dat)?

[Sebazzz]

Het klinkt meer alsof TRIM niet aanstaat voor je schijf.

[aawe mwan]

Sebazzz schreef op zondag 31 juli 2022 @ 17:31:
Het klinkt meer alsof TRIM niet aanstaat voor je schijf.

TRIM gaat over blokken waar geen data in zit en dat heeft dus niets te maken met dit probleem.

Daarnaast staat fstrim natuurlijk gewoon aan (default in Ubuntu).

[aawe mwan]

Ik heb ook nog gekeken naar de suggestie om een „sparse” imagefile te maken van de drive. Dat is een bestand waarin de blokken die volledig uit nullen bestaan worden weggelaten. Bij het terugschrijven van zo'n sparse imagefile, schrijft hij die nul-blokken niet. En dan hoop je dat dit precies de ongebruikte blokken zijn.

# Wat is in gebruik:
$ df -h | grep 'Filesystem\|mmcblk1'
Filesystem      Size  Used Avail Use% Mounted on
/dev/mmcblk1p2   28G   14G   14G  50% /
/dev/mmcblk1p1  511M  5,3M  506M   2% /boot/efi

# Hoe zie je dit in de sparse image:
$ ls -lhs sparse-emmc.bin
17G -rw------- 1 xxx xxx 29G jul 31 19:03 sparse-emmc.bin

Het verschil tussen de 29GB en de 17GB zijn de blokken die volledig 0 zijn. Dit is net iets meer dan wat er op de drive in gebruik is. Maar waarschijnlijk bevatten sommige bestanden ook blokken die volledig nul zijn.

En het probleem is dan dat als ik een imagefile wil maken en restoren, ik de drive wel zal moeten unmounten. Maar juist de eMMC drive is de opstartdrive.

[aawe mwan]

Dit is het beeld van mijn /dev/sdc1. Het is een SATA drive dus hij is sowieso niet zo snel.

De blokken aan het eind van de drive, die met 400MB/s gelezen worden, zijn waarschijnlijk met TRIM vrijgegeven blokken (misschien leest de drive die niet eens echt uit NAND). Verder zie je hier en daar gebieden waar de meeste blokken met zo'n 385MB/s te lezen zijn; dit is vers geschreven data. Ook in het begin van de drive vind je zo'n stuk, omdat ik de eerste 10GB al een tijd geleden een opfrisbeurt gegeven heb.

Het gebied rond de 200GB bevat oude data, die ik in juni 2019 geschreven heb (ik zie het aan de datum van de directories). De leessnelheid in dit gebied schommelt tussen de 75 en 220 MB/s, met uitschieters naar beneden tot niet meer dan 44MB/s.

Ik heb deze meting meerdere keren herhaald en steeds zie je hetzelfde beeld.

$ df /dev/sdc1 --si
Filesystem      Size  Used Avail Use% Mounted on
/dev/sdc1       984G  618G  316G  67% /home

Ik heb de meting als volgt gedaan. Met pv heb ik alle sectoren van de drive gelezen en daarbij heb ik pv het totaal aantal gelezen bytes 2 keer per seconde laten loggen naar een ramdisk. Dit deed ik met "nice" zodat het proces een zo hoog mogelijke prioriteit kreeg. Met een awk programma bereken ik er achteraf een derde kolom bij, met het aantal bytes per seconde. Het resultaat plot ik met gnuplot. Daarbij gebruik ik opacity, omdat de samples overlappen en zonder dit zouden de lage waarden onzichtbaar worden.

Bash:

sudo \
nice --adjustment=-20 \
pv /dev/sdc1 --buffer-size 1M --numeric --timer --bytes --interval=0.5 \
>/dev/null 2>/tmp/ramdisk/pv.sdc1

FILE=pv.sdc1.gnuplot

awk --use-lc-numeric \
'BEGIN '\
'  {o1=0; o2=0} '\
'$1!=o1 '\
'  {printf ("%f" FS "%i" FS "%i" ORS '\
'          , $1    , $2   , ($2-o2)/($1-o1) ); '\
'   o1=$1; o2=$2}' \
</tmp/ramdisk/pv.sdc1 >$FILE

gnuplot -p -e \
 'set format x "%.1s%cB" '\
';set format y "%.1s%cB/s" '\
';set grid '\
';plot "'$FILE'" '\
' using 2:3 '\
' with boxes '\
' linecolor rgb "#ee007733" '\
' title "'$FILE'"'

[ Voor 18% gewijzigd door aawe mwan op 14-08-2022 09:19 . Reden: bash code leesbaarder gemaakt ]