Svenska ElektronikForumet

Gör TRIM blocken otillgängliga eller är det bara en markering "använd när det börjar bli ont om plats" ..? i det senare fallet är det ju bara att ge f-n i att skriva något övh och köra återhämtning av filer direkt.

Om de TRIM:ade blocken göms (likt SCSI reallocation sectors) så borde det finna kommandon för att plocka fram dessa.

Nej det finns det inte.

MAO hade jag pissetur att jag kunde rädda datan.. fy

Kan man nog säga.

Senare Sandisk-SD har TRIM i sig och/eller försöker få det till standard även på SD-kort - så det är inget självklart att de är 'trim'-fria i alla lägen och framförallt inte det som köps idag. Även USB-minnen börja komma med trim-support (tex. kingston)

Sannolikt för att SD-kort dels riktar till fotografer mm. där man vill ha hög bildundanlagringskapacitet och prestandan påverkas mycket om GC måste radera varje ej blankad block för varje ny block som skall skrivas om SD-minnet har blivit fullskriven minst en gång och de blankade blocket i den gömda utrymmet tagit slut.

Då är det behändigt om datorn som kopierar och raderar filerna på SD-kortet, med 'trim' berättar vilka sektorer om inte längre har valid data och tillåter GC att radera/blanka ut dessa när den har möjlighet.

till detta så blankar flash ett eller antal block mycket snabbare än att tex. att skriva linjärt med 'FF' eller '00' med något program (är det 16, 32 eller 64 GB så tar det en stund även om det skriver med många MB/s - det sista kräver också kännedom om det är 'FF' eller '00' som motsvarar en oskriven sektor och inte utlöser en blockradering och därmed tidsåtgång.

Eftersom man ändå stoppat in en GC. resevsektorer, felrättning så är inte steget långt till att implementera TRIM och den vägen ge tips till GC vilka block denne kan radera och inte bara den delen som är gömd bakom skynket för att kunna slänga fram ett mindre antal blankade block när skrivordrarna kommer och samtidigt stuva undan det som skulle skrivas över för senare blankning när det finns tid för det.

Jag har ju för fasen 32 GB SD-kort komplett med inbyggd Wlan och webbserver på denna - att införa 'trim' torde vara en smal sak i dessa sammanhang.


Den andra delen är att SD ser ut att bli allt mer accepterad som masslagringsenhet i tex. microkontroller-applikationer istället för en inlödd flash där man själv måste hantera wear-levlingen i filsystemet (vilket skapar utrymmer för allvarliga misstag som kanske först upptäcks efter flera år för att någon programsnutt har skrivit till samma sektor hela tiden, om man inte kör med välprovade bibliotek och filsystem som är skapade för just detta - fel av denna typ kanske fungerar i konsumentprylar men är inte OK i prylar som används i infrastruktur och skall fungera väldigt lång tid.) - skönt då med en SD-kort som sköter allt sådant själv och presenterar sig som en disk sas.

Jo, det kan jag hålla med dig om, steget är ju inte långt, iom att kapaciteterna och hastigheterna ökar.

Finns sedan gammalt raderkommandon i SD-card specifikationen - dock kan det bara radera i typ 128 - 256 sektorer i stöten för att chip-geometrin ser ut så (och detta går ganska fort i jämförelse med att fylla minnet med '00' eller 'FF' på sedvanlig väg.)

har dock inte riktigt koll om GC i SD-chippet kopierar och reallokerar datat runt omkring sektorerna man vill radera om det är betydligt mindre än ett helt block i stöten, så som som SSD:s 'trim'-kommando gör. - sådan kräver lågnivå-pill att kontrollera och vet inte om det finns några bra vägar för sådant i tex. linux.

Dom vanligaste omformateringsprogrammen som i windows etc. ser SD enbart som en disk och behandlas därefter utan att ta några fördelar av enheten eventuella fördelar som att kunna radera snabbt blockmässigt.

dock finns det en SD-formatter från www.sdcard.org som förhoppningsvis gör det på den effektivare sättet om man väljer optionen 'full (erase)'
och hittas https://www.sdcard.org/downloads/formatter_4/