Intenso external SSD Premium 1TB Antraciet

Dat verschil ga je dan sowieso wel merken. De access times zijn vele malen lager bij een SSD. Ook zal de SSD minder snel falen dan een SD kaartje. Het wegschrijven van logs en flushen naar de database is niet zo geweldig voor dat SD kaartje (hoewel Home Assistant hier al veel optimalisaties voor gedaan heeft).

Geef me een seintje als jouw review online staat, dan zet ik er een link naar in mijn review.

Heb je deze test van TomsHardware betreffende soorten storage op RPi's al gelezen? Ik vond hem wel interessant.

Veel plezier!

Ik ben het eens met je dat na verloop van tijd er vertragingen kunnen optreden. Ik ben het echter niet volledig eens met de enkele oorzaak die je hieraan toeschrijft. Ik schrijf het hieronder even uit; niet specifiek naar jou toe, want jij weet het meeste al, meer naar eventuele andere lezers toe die deze informatie wellicht ook interessant vinden.

Als je schrijft over buffers (of cache in het Engels), dan zijn hier enkele varianten in en telkens bestaat er een leescache en een schrijfcache.

De leescache is er voor data die eerder al gelezen is, in een sneller geheugen paraat te houden zodat de tragere drive niet onnodig moet gelezen worden. De schrijfcache is er om een save of copy actie sneller te doen lijken af te ronden waardoor de gebruiker verder kan, maar in de achtergrond de schijf eigenlijk nog steeds aan het opslaan is. Indien dit nog gebeurt, dan is het natuurlijk belangrijk dat de usb drive niet uit de computer getrokken wordt. Hiervoor was er bvb de windows-functie "uitwerpen" of "eject" waarbij Windows de schijfbuffers wegschreef naar de stick en nadien aangaf wanneer het veilig was om de stick te verwijderen.

Je hebt dus een cache in een vluchtig geheugen. Dit vluchtige geheugen kan op 2 plaatsen zitten. Dit kan enerzijds zitten in Windows, jouw computergeheugen (RAM) wordt dan gebruikt als lees- of schrijfcache en wordt beheerd door Windows.
Dit geheugen kan echter ook zitten op de drive zelf. Hier heeft Windows geen controle over. Indien we spreken over usb drives, dan gaat dit meestal enkel over leescache. Data die al gelezen is, wordt hierin opgeslagen en met voorspellende algoritmes wordt er vaak een precache gedaan van data die wellicht nadien gevraagd zal worden.
Vluchtige schrijfcaches op een usb drive komen veel minder frequent voor omdat dit duur is. Deze schrijfcaches worden namelijk ook steeds voorzien van een kleine batterij of capacitor zodat de schijf nog voldoende tijd heeft om deze cache weg te schrijven naar het permanente geheugen bij stroomverlies.
Dit zie je echter wel vaker terugkomen bij enterprise- of datacenterhardware.

Vervolgens heb je nog een truckje dat fabrikanten vaak gebruiken om schrijven sneller te maken. Om dit te begrijpen moet je eerst begrijpen dat er bij flash storage verschillende soorten zijn.
Een vereenvoudigde uitleg is als volgt:
Een bit is een 1 of een 0. Bij flashgeheugen is dit "stroom" of "geen stroom". Als je dus 8M nulletjes en eentjes kan opslaan, dan heb je 1MB aan dataopslag. Dit noemen ze SLC geheugen. (= Single Level Cell).

Met als doel meer data op 1 chip te krijgen, hebben ze MLC bedacht. (Multi-Level Cell). Hier werden per cell niet 1 bit, maar 2 bits opgeslagen. Dit kon dus zijn 00, 01, 10 of 11. Dit betekent dat ze niet "stroom" of "geen stroom" hebben, maar "0% stroom", "33% stroom", "66% stroom", "100% stroom". Het voordeel is dat je effectief jouw opslagcapaciteit verdubbelt, maar dat na verloop van tijd de data sneller corrupt geraakt én dat je als je 1 bit wilt wijzigen, je eerst ook de andere moet lezen en beiden nadien opnieuw moet wegschrijven. Dit vertraagt het schrijven. Nadien zijn er ook nog TLC en QLC geheugen gekomen (Triple en Quad) telkens met dezelfde voordelen nadelen.

Het truckje dat fabrikanten dus gebruiken om sneller schrijven mogelijk te maken is door een deel SLC geheugen op de drive te plaatsen als snel schrijfgeheugen en de rest met goedkoper [M/T/Q]LC geheugen.
Wanneer de drive niets moet doen, dan begint hij het SLC geheugen weg te schrijven naar het tragere geheugen.
Het nadeel is hier -zoals keuringsdienst correct aangeeft- dat als je op een 1TB drive bvb 16GB aan SLC geheugen hebt en de rest als QLC geheugen, je na een groot bestand van ~16GB zal zien dat de snelheid plots keldert.

Er zijn echter nog andere oorzaken waarom de performance na een tijd keldert. Net als een processor, moet een controller allerhande zaken berekenen (zeker bij de niet-SLC geheugentypes). Des te sneller deze is, des te sneller de schijf is. Maar ook: des te warmer deze wordt. Ook hier kan een controller sneller zijn als deze beschikt over meerder pipelines (zeg maar threads) of sneller geclocked is. In een van mijn andere reviews heb ik een Sandisk onder de loep genomen die tot 52°C werd - zeer onaangenaam om deze vast te nemen. Eenmaal >50°C werd deze erg traag omdat deze begon terug te throttelen om zichzelf te beschermen tegen oververhitting.

Mijn persoonlijke mening naar "keuringsdienst" is dan ook dat ik het helemaal niet eens ben met deze uitspraak:

Maar eigenlijk zeggen synthetische tests helemaal niets over de echte snelheden.
Het is op zijn best een indicatie over het maximaal haalbare, maar meer ook niet.

Natuurlijk zeggen synthetische tests iets over de echte snelheid: vergelijk een synthetische test tussen een SATA HDD, en SATA SSD of een NVME SSD en je ziet direct grote verschillen. Kijk zelfs naar de verschillen tussen verschillende usb sticks en je ziet ook een groot verschil. Afhankelijk van het type synthetische test, laat je echter verschillende aspecten van de drive zien en je moet de kennis hebben om deze te interpreteren.
Los van mijn mening, als synthetische tests niets zouden zeggen, waarom worden deze dan gebruikt door elke tester? Welke wijsheid moeten namen als Jays2cent, Linus, TomsHardware en zelfs Tweakers nog leren als deze tests niets zeggen?

Je kan de bottleneck voor de doorvoersnelheid achterhalen (zij het type usb, de controller of de flash chips) (dit zijn de grote I/O size transfers), je kan de belemmerende factor van de microcontroller of flash chips achterhalen en een worst-case scenario zoeken (de kleine I/O sizes - wat een test is voor de IOPS van de schijf).
Je kan ook stresstests doen om de thermals te achterhalen en -zoals keuringsdienst terecht aangeeft- eventuele SLC buffers.
De waarheid ligt IRL steeds ergens tussenin en hangt enorm af van de use-case van de gebruiker.
Analogie: Een Ferrari is sneller dan een Jeep. Tot je in de jungle moet rijden... Use case is key...