Precis - USB-stickorna och SD-minnen tar den flashen som inte går att sälja till mer krävande kunder, vilket gör att det också är samma typ av flash-tekniker och generation som används i rådande produktion av SSD/NVMe eftersom det är sådana i sekundär och ännu sämre kvalitet fins att köpa i stor mängd billigt hos de olika flashminnestillverkarna. dvs tillverkas det stora mängder QLC-minnen hos flashtillverkarna så kommer snart de mindre lyckade exemplaren också finnas i köpta USB-stickor och SD-minnen - och dessa skriver heller inte vad det är typ av flashminne i USB-stickan och nästa månadens batch hos en noname är kanske av annan tillverkare av flashminnena, beroende på vad man lyckades köpa på spotmarknaden ungefär...
Nu finns det nivåer på det här helvetet också och köper man från Samsung som nämnda Samsung BAR, från Kingston etc. med en lägsta ribba kvalitetsmässigt så är det inte bottenskrapet som stoppas in i dessa medans köper man USB-minne från Wish så är det risk att man får flashminnen som verkligen är längst ned i trash-bin hos flashtillverkarna...
Jag provade att mäta lite på mina +5 år gamla Samsung Bar 64 GB - med lite annan kapseldesign än dagens. Till min smula förvåning så fungerar UASP på denna och den accepterar unmap-kommandot (motsvarande TRIM) utan dumma, krascha eller ger error som Sandisk extreme-stickorna gör
Läshastigheten var runt 115 MB/s och skrivhastigheten runt 34 MB/s när jag skrev med 40 GB med slumpvärden (alltså ej komprimerbart) då stickan hade en del data i sig redan, vilket i princip uppfyller TS krav. - men skrivhastigheten gäller bara en gång, innan man har skrivit skrivmängden som motsvarar hela stickans lagringsvolym - efter det går det inte fort då stickan måste börja reallokera och radera flashblock och skrivhastigheten kan gå under 1 MB/s för lite större filer och det skriver väldigt ryckigt.
Och där blir den kvar med usel skrivprestanda om man inte kör TRIM/unmap-kommandon över UASP, för USB-stickorna som stöder det över huvud taget, gärna också i kombination med 'zerofill' - dvs. göra jättefil fylld med enbart '0' för att ta allt ledigt utrymme som är kvar på USB-stickans filsystem och sedan radera denna och efter det kör man fstrim (i linux) - både zeroskrivningen och fstrim gärna i 2 omgångar då när fstrim körs så skickas det förvisso mängder med unmap/TRIM-kommandon men stickan verkar bara ta en del av dessa och ignorerar resten för att den har inte kapacitet att hantera det när alla kommer på en gång. - tyvärr fins ingen 'smoth'-mode där den skickar ut TRIM-kommando i små grupper över längre tid i Linux - vilket windows gör när den städar med TRIM efter en raderad större fil.
Man kan undra varför man i dylika prestandatester inte skriver flashminnet fullt med minst 2 gånger flashminnets volym med slumpdata innan man börja med prestandamätningarna?? För det är där folk hamnar förr eller senare när USB-stickan har använts ett tag! - eller så hoppas man på att stickan tappats bort innan den fulla volymen på stickan har skrivits - ibland känns det lite så...
Slutsatserna är att stickorna kan ge den utlovade skrivhastigheten - men bara tills man skrivit upp stickans hela datavolym (dvs. skrivit 64 GB i datamängd på en sticka som är 64 GB stor sedan stickan öppnades ur förpackningen ) - efter det så kommer skrivprestandan vara ynklig tills man gör TRIM-operationer över USB-bussen och kanske i flera omgångar innan all ledig utrymme blivit raderat igen för snabb skrivning.
Problemet är att de allra flesta OS-miljöer skicka ingen TRIM över USB, inte ens linux (inte den versionen jag kör i alla fall) även om det går att slå på med lite filskriving och instrurerar udev att göra detta¹.
Jag har inte koll på win11 men räkna inte med att windows gör det heller då det räcker inte med att få den att använda UASP-protokollet över USB mot USB-stickan i dataöverföringar (istället för att använda den äldre USB-protokollets BOT-protokoll) - utan den skall också rekognosera USB-stickan som antingen en SATA-disk via AHCI eller som en SCSI-disk innan TRIM vid filradering börja fungera på USB-stickan, heter det något annat så körs det ingen trim alls.
Det här gäller all inkopplad flashminne över USB - gör man inte TRIM/unmap då och då så kommer skrivprestandan att sjunka när lagringen har skrivits med hela sin lagringsvolym i mängden skrivningar. - det gäller också eSSD som samsung T-serien
- jag spelar ibland in videoströmmar i runt 200MB/s klassen med SDR-mottagare och har man inte kört fstrim på filsystemet på T7 innan så kommer inspelningen att misslyckas efter en tids inspelning och det börja stalla och hacka - på SSD/NVMe-lagring som skryter med 900 MB/s i skrivhastighet - och det vill man inte ha vid en realtidsinspelning. Detta märks inte direkt utan kanske kommer efter 1 timme och en 4 timmarsinspelning visade sig bli 8 timmar innan disken är full för att skrivningen av eSSD gått ned ordentligt och videoinspelningen är svårt söderhackad tidsmässigt. - ibland fungerar det bättre att köra på en stor snurrdisk med nyformaterad filsystem - nej, jag skojar inte...
¹ hur man i Linux aktivera TRIM/unmap över USB mot inkopplade eSSD och USB-stickor i UASP-protokoll och som har unmap-support.
cd /etc/udev/rules.d
i denna skapar man en ny textfil (om inte filen redan existerar) i en texteditor med filnamnet "50-usb-ssd-trim.rules"
i denna skriver man (som en rad):
ACTION=="add|change", ATTRS{idVendor}=="090c", ATTRS{idProduct}=="1000", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
har man fler enheter så skriver man motsvarande för den i en rad under.
idVendor och idProduct kan letas fram med 'lsusb' för just _din_ USB-lagring, ovan gäller för samsung BAR tillverkad för ~5 år sedan och kan vara annat idag.
spar textfilen och se till att ägare, group samt rättigheter är samma som de andra filerna i mappen.
efter detta kan man ansluta sin lagring och då bör 'fstrim' fungera på enhetens filsystem om enheten i slutändan supporterar detta.
