Hoe maak ik een micro SD kaartje weer snel?

[aawe mwan]

Ik heb twee "Sandisk Ultra" micro SD kaartjes van 16GB, class 10.
De ene heb ik een paar jaar geleden gekocht (en nauwelijks gebruikt), de andere vandaag, in dezelfde winkel.

Naar beide kaartjes heb ik vandaag een Raspberry Pi image geschreven en daarbij viel me op dat het nieuwe kaartje veel sneller is dan het oude:

Het nieuwe kaartje is 10MBps schrijven, 20MBps lezen
Het oude kaartje was in eerste instantie 6MBps schrijven, 18MBps lezen,
maar na een paar keer benchmarken was het nog maar 4½MBps schrijven, 18MBps lezen.

Ik vermoed dat dit komt omdat het oude kaartje altijd met een image volgeschreven geweest is en er dus geen echt vrije blokken meer op staan. Bij een SSD kan je ongebruikte blokken vrijgeven met fstrim; dat heb ik ook geprobeerd op dit kaartje maar die herkent het kaartje niet en weigert iets te doen.

Hoe kan ik dan toch mijn oude micro SD kaartje weer snel maken?

[Q]

Ik heb geen goed antwoord op je vraag.

Wat ik wel kan adviseren: om voor een Raspberry Pi een SD kaartje van de categorie A1 te kopen omdat deze kaartjes zoveel beter presteren dan niet-A1 kaartjes dat het de 'investering' meer dan waard is.

[jeroen3]

Je kunt kijken of fstrim in linux werkt.

[4POX]

Je kan de gratis applicatie minitool partitioner gebruiken om een SD card te wipen met nullen. Dat heeft bij mij geholpen om de Sandisk extreme PRO usb stick weer snel te maken omdat Sandisk is vergeten een garbage collector in de firmware te bakken.

Moet wel toegeven dat ik erg veel van die Sandisk en Samsung (Samsung wat vaker) class 10 kaartjes heb weggegooid de laatste jaren. Ze gaan zomaar stuk als je ze gebruikt in een raspberry of andere intensieve apparaten.

Als je een nieuwere generatie Raspberry Pi hebt kan je ook booten van USB. Je kunt dan een goedkope 128/256 GB SSD gebruiken die alle foefjes aan boord heeft om snel te blijven.

[Admiral Freebee]

Ik zou het eens proberen met de SD Memory Card Formatter van de SD association. Deze kan ook alle data terug verwijderen (overschrijven) waardoor alle blokken terug klaar zouden moeten zijn om een write te ontvangen.

https://www.sdcard.org/downloads/formatter/

[Ben(V)]

Uiteraard zal een formatter ook niets anders kunnen doen dan de interne sd controller opdracht te geven iets te wissen en die zal die blokken dan ook weer enkel als ongebruikt markeren maar pas echt wissen op het moment dat je er iets naartoe wilt schrijven en dat kost dan extra tijd.

Het zit allemaal ingebakken in de controller van de sd kaart en als hij geen trim ondersteund is daar gewoon niets aan te veranderen.

[aawe mwan]

Is het dan zo dat als een blok helemaal vol staat met nullen, dat het kaartje dan zelf weet dat hij zo'n blok niet meer eerst hoeft te wissen?

Ik zou dit kunnen uitproberen: als ik 16GB aan nullen naar het kaartje schrijf, zou het schrijven op een gegeven moment ineens weer snel moeten worden.

Een verschil tussen het oude en het nieuwe kaartje is trouwens wel dat het nieuwe kaartje een "A1" markering heeft en het oude niet.

[Q]

Ha!

Het probleem van SD kaartjes is dat ze doorgaans hele slechte random write performance hebben.

De A1 en A2 classificaties eisen dat SD kaartjes een minimum halen, wat ik zo niet meer weet maar stukken beter is dan non-Ax kaartjes.



Conclusie: jouw non-A1 kaartje gaat nooit zo goed presteren als het A1 kaartje.

[ Voor 50% gewijzigd door Q op 22-06-2020 17:12 ]

[Renault]

Ik denk dat de snelheids-rem een hardware-probleem is: nieuwere kaartjes zijn meestal gewoon sneller dan oudere kaartjes.

[Q]

Renault schreef op maandag 22 juni 2020 @ 17:47:
Ik denk dat de snelheids-rem een hardware-probleem is: nieuwere kaartjes zijn meestal gewoon sneller dan oudere kaartjes.

Nee, de A1 / A2 classificatie maakt een groot verschil. Een nieuw non-Ax kaartje kan net zo beroerd presteren als eentje van 10 jaar oud.

Zeker als je een kaartje voor een Raspberry Pi wilt gebruiken is het echt een aanrader om voor een A1 / A2 kaartje te gaan, A1 is goed genoeg. (A2, vereist speciale ondersteuning).

https://www.jeffgeerling....rformance-comparison-2019

[ Voor 27% gewijzigd door Q op 22-06-2020 17:56 ]

[aawe mwan]

Grappig dat je de blog van Jeff Geerling noemt, want ik volg momenteel zijn Ansible cursus op YouTube.

Blijkbaar, als je ook kijkt naar oude testen van Jeff, worden de "Sandisk Ultra" kaartjes door de jaren een heel klein beetje sneller, ook al blijven ze dezelfde naam houden. Als je performance nodig hebt, dan is het alternatief tegenwoordig een SSD op USB3, maar bij Jeff zie ik dat je dan geforceerde koeling nodig hebt.

(toevoeging: de koeling is nodig voor de USB3 controllerchip op de Raspberry Pi 4)

[ Voor 11% gewijzigd door aawe mwan op 28-06-2020 17:00 ]

[Renault]

Dat laatste geldt voor zover ik weet alleen voor NVME-SSD's, omdat die veel meer hitte genereren dan SATA-SSD's.

Ik vermoed dat dat óók geldt voor M2-SATA SSD's omdat die in vergelijking met 2,5" SATA SSD's wat kwetsbaar zijn en dus in een M2-behuizing worden gebruikt.
Maar ik zou geen enkele reden kunnen bedenken waarom je een M2-formaat SATA SSD in een externe versie zou willen gebruiken: een 2,5" versie ervan is gemakkelijker en minder kwetsbaar.

[Q]

aawe mwan schreef op maandag 22 juni 2020 @ 19:54:
Grappig dat je de blog van Jeff Geerling noemt, want ik volg momenteel zijn Ansible cursus op YouTube.

Grappig, ik gebruik zelf veel Ansible en genereer zelfs images voor VMs, wat ik ook wil gaan gebruiken om custom RPi images mee te genereren.

Blijkbaar, als je ook kijkt naar oude testen van Jeff, worden de "Sandisk Ultra" kaartjes door de jaren een heel klein beetje sneller, ook al blijven ze dezelfde naam houden. Als je performance nodig hebt, dan is het alternatief tegenwoordig een SSD op USB3, maar bij Jeff zie ik dat je dan geforceerde koeling nodig hebt.

In hoeverre je om de absolute waarden geeft: de officiele A1/A2 test moet met een datasize van 200 MB getest worden, maar Jeff test met 100 MB dus zijn waarden zijn ietsje beter, maar zijn tests zijn prima om de onderlinge verschillen bloot te leggen.

[aawe mwan]

Het is inderdaad wel een HEEL erg groot verschil tussen het kaartje zonder en het kaartje met A1, wat meteen opvalt bij een apt upgrade. Veel meer dan de factor 2 die ik al zag bij het schrijven van een image.

[Q]

aawe mwan schreef op donderdag 25 juni 2020 @ 18:12:
Het is inderdaad wel een HEEL erg groot verschil tussen het kaartje zonder en het kaartje met A1, wat meteen opvalt bij een apt upgrade. Veel meer dan de factor 2 die ik al zag bij het schrijven van een image.

Een apt-get upgrade is precies het scenario waar een A1 kaartje uitblinkt.

Een image schrijven naar een SD kaart is nog relatief eenvoudig: sequentieel data schrijven. Dat gaat nog redelijk.

Maar een apt-get upgrade veroorzaakt heel veel random writes en waar een A1 kaartje minimaal 500 IOPs moet halen, zal een non-A1 kaartje - zo heb ik gemerkt met mijn eigen tests - vaak maar 40 tot 50 IOPs halen.

Dat is geen typefout. Ik heb zelfs kaartjes gehad die onder de 30 IOPs random writes gingen.

Met andere woorden: de prestaties van non-A1 kaartjes zijn slechter dan die van een laptop hardeschijf qua random IOPs.

Daarom is dat artikel van Jeff Geerling zo belangrijk. Ik zou willen dat meer mensen dit zouden weten want ze kopen een RPi4 en dan hebben ze een 'klote' ervaring omdat ze een verkeerd of ongeschikt SD kaartje gebruiken.