Skrivet av Pirum:
Har flera äldre stickor som håller sin hastighet (säg 40Mbyte/s) rakt igenom, efter många år, dessa nya verkar mer lynniga.
Därför att det är TLC och snart QLC-minne i alla USB-stickor man köper på gubbdagis idag - SD-minne och USB-stickor lever på 'left over' av flashmedia som ingen annan vill betala något för - därför speglar innehållet vad som produceras just nu på flashminnes-fabrikerna och är det massor med QLC-minne med dålig yeld som dumpas så är det detta vi kommer att finna i våra SD-minnen och USB-stickor lite senare...
Troligen fungerar dina gamla stickor bra för att det är stickor med MLC-minnen - sådant som inte går att få tag på i konsumentnivå idag utan möjligen som skitdyra USB-donglar av industrial quality för tex. bootning av server för hur mycket pengar som helst.
---
Normalt kör man inte TRIM över USB för att det helt enkelt inte finns stöd för detta i standard windows och för lagring som inte jobbar under AHCI (dvs. direktkopplad via SATA-kabel) även om SSD-Chipet vid SMART-frågor bakom USB/SATA-brygga säger att det stöder TRIM och därför är de flesta OS helt blinda för detta och TRIM/optimering kunde oftast bara göras av lagringsmediats (tex sandisk) egna program och även den delen har varit skakig för Sandisk där stödet har försvunnit och kommit tillbaka emellanåt med programversionerna.
- Det är först med UAS(P) stödet i använda USB-bryggchipset som detta med trim över USB möjliggjordes och man skickar den ekvivalenta SCSI-kommandot 'unmap' den vägen - men det är skakigt fortfarande på många USB-SSD då de inte klarar köade kommando när TRIM skall göras i SATA-protokollet som det har varit skrivet hittills och lösningen för detta definierade in i USB3.1 för typ 9 år sedan men ännu inte slagit igenom på alla håll...
För moderna USB-SSD lagringar med NVMe bakom sig (som samsung T7) och inte USB/SATA-brygga och SATA-kontroller mot lagringen så är köad TRIM/unmap inte ett problem då detta är löst i och med NVMe-lagringen och där byggde bort sådana flaskhalsar redan från början.
---
I linux kan man öppna USB-enheter för 'TRIM' med att under /etc/udev/rules.d/50-usb-ssd-trim.rules
skapa filen om den inte redan finns och skriva i denna:
"ACTION=="add|change", ATTRS{idVendor}=="0781", ATTRS{idProduct}=="5580", SUBSYSTEM=="scsi_disk", ATTR{provisioning_mode}="unmap"
och så gör man en ny rad för varje typ av sticka/lagring man vill koppla in över USB baserat på dess USB-ID nummer.
idVendor och ideProduct får du leta fram med 'lsusb' för just din USB-sticka
och ser typiskt ut
Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 004: ID 0781:5580 SanDisk Corp. SDCZ80 Flash Drive
Bus 002 Device 002: ID 04e8:4001 Samsung Electronics Co., Ltd PSSD T7
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 002: ID 2109:3431 VIA Labs, Inc. Hub
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
och andra raden på denna är USB-id för Sandisken som jag matat in i ovanstående regel.
spara filen och innan den blir aktiv så måste man ta ut USB-stickan och sätta in den igen så att udev arbetar och ser enheten och går allt bra så ser det liknande med 'lsblk -D'
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
.
.
sda 0 512B 4G 0
sdb 0 512B 4G 0
└─sdb1 0 512B 4G 0
mmcblk0 0 4M 116.5G 0
├─mmcblk0p1 3145728 4M 116.5G 0
└─mmcblk0p2 3145728 4M 116.5G 0
Då USB-sticka nu här har benämningen /dev/sdb och har 512 Byte som minsta TRIM-block och 4GB som största block
[Det intressanta är att mmcblk0 också stöder TRIM (är en sandisk microSD ultra) - alltså en SD-brickan har trim-support (denna exempel körs på en Rasberry PI4 med ubuntu) och det gick bra att köra "fstrim -v /" utan problem på denna]
Om man sedan monterar med 'mount -o discard /dev/sdb1 /media/användare/USB-sticka" så bör man få en mapp där när filerna raderas så skickas TRIM för platsen för filerna som raderas - och för att rensa hela volymens lediga utrymme så kan man prova med "fstrim -v /media/användare/USB-sticka" men det är ingen garanti att det fungerar då buggar i USB-stickans firmware kan spela spratt!
man kan få fel som kan läsas fram med 'dmesg':
"sd 1:0:0:0: [sdb] tag#0 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE cmd_age=0s
[ 5094.830499] sd 1:0:0:0: [sdb] tag#0 Sense Key : Illegal Request [current]
[ 5094.830509] sd 1:0:0:0: [sdb] tag#0 Add. Sense: Invalid command operation code
[ 5094.830520] sd 1:0:0:0: [sdb] tag#0 CDB: Unmap/Read sub-channel 42 00 00 00 00 00 00 00 18 00
[ 5094.830527] blk_update_request: critical target error, dev sdb, sector 76104 op 0x3:(DISCARD) flags 0x800 phys_seg 1 prio class 0"
Som med denna sandisk-sticka... men fungerande glimrande på en Samsung T7 och för den delen på microSD som OS själv körde på.
när det kraschat så stänger OS av automatiskt 'discard'-försöken på stickan i linux och man ser det också med lsblk -D med:
NAME DISC-ALN DISC-GRAN DISC-MAX DISC-ZERO
.
.
.
sdc 0 512B 0B 0
└─sdc1 0 512B 0B 0
att DISC-MAX som stod på 4GB förut nu står 0B i storlek - TRIM/unmap/discard är avstängt.
När man provar som ovanstående så får man ha i bakhuvudet att använda USB-sticka förutom fel som ovanstående också kan korrumpera existerande data och kan tom. sluta att fungera helt - det är så mycket buggiga firmware som snurrar runt i olika lagringsmedia och vi pratar om det som snurrar i själva USB-stickan själv, med andra ord töm och ha inget viktigt på stickan innan prov! och prova ordentligt med olika testprogram med att skriva testfiler och ta bort dem, kolla de stora filerna med tex. mediafiler (hyffsat slumpartat och icke komprimerbara) med hashvärden före och efter att inte datat korruperar sig även när stickan är nära full.
---
När stickan inte fungerar med TRIM-funktion med sådana övningar som ovan så är det närmaste man kan komma en sådan 'TRIM' att man fyller hela stickan med binär '0' (i Linux-miljö här) och kan tex. göras med:
"dd if=/dev/zero of=/dev/sdb bs=1024k status=progress <enter>"
- /dev/sdb är då stickan som skall 'nollas' och det bästa är att man kollar med 'lsblk' precis innan att man kör på _rätt_ enhet innan man trycket på <enter> - för det nollställer disken och det finns inget sätt att rädda data i efterhand hur mycket man än är villig att betala.
Detta bygger på att nästan all flashmedia med egen kontroller i sig gör 'trim' själv när tillräckligt stora block av sammanhängande data fylls med "0" - i somliga fall när "FFh" laddas på samtliga sektorer och det har och göra med bakomliggande NAND-flash vilket som fungerar. - detta förutsätter också att man inte har någon aktiv kryptering påslaget vilket i sin tur kan göra det knepigt i media som alltid krypterar (osynligt) och då är det bara 'TRIM'/unmap som fungerar om enheten kan ta emot dessa kommandon - i värsta fallet bara med tillverkarens egna mjukvara med 'optimize' - och sista chansen är om det går att göra security erase om USB-stickan presenterar sig som en SATA-disk och kan läsa ut SMART-värden från denna när den är inpluggad (och om du frågar mig så är det för bökigt och måste göras i rätt ordning för att inte bricka lagringen för att det skall vara värd besväret)
