SD-kortet har hyss för sig?

Men vad gör du med det. Ingen aning vad du pysslar med..
Antar att det är begränsat antal skrivningar till ett SD kort men det finns någon form av *distributed wear leveling*, kan du ha skrivit så många gånger att kortet börjat degradera ??

@Sweedland: är du säker på att det är kortet som strular? använder du kortläsaren i fronten på datorn eller en usb kortläsare?
testa att sätta kortläsaren i bakänden av datorn och då i en usb 2 port ( om det inte är en usb 3 kortläsare)
Brukar se problem när jag för över många små filer från sd kort om jag inte gör som ovan.
är det skrivfel på kortet från när filen skapades kan det ge intressanta fel såsom omöjligt att flytta filen mm

SD-kort är långsamma, men skrivningar läggs ju i buffer å skrivs så fort som möjligt. Det kan ju bli problem om du skriver så pas snabbt, mycket å ofta att buffern blir full.

i Unix-världen förr så skrev man reflexmässigt 'sync' två gånger i rad i consolen efter olika skript som innefattade skrivningar mot disk för att försäkra sig att allt som låg i filbuffrarna skrevs ut till media[1].

Du kanske får prova med något liknande eller öppna filerna i 'sync' mode om det går med flaggor.

---

Du får leta fram gamla och skitlångsamma SD-kort från början av 2010 med SLC-celler i sig om det skall vara något så när säkert.

en variant i nutid är 'industrial' SD-kort liknande

https://www.elfa.se/sv/industrial-sd-kort-gb-xmore-industrial...

och man får betala för det också...

Att gå upp till snabbare kort och större storlek i konsumentklass har motsatt verkan då dels är MLC och TLC-minne i dem med låg tålighet mot omskrivning och kort lagringstid - samt att det är baserat bottenskrapet av minnechip som stoppas i dem - dvs. minnen som klassat inte duger för inbyggnad eller SSD.

skall du skriva och läsa mycket så föreslås istället USB-snurrdisk eller SSD-minne i en USB-kabinett som masslagring och använder SD-bricka enbart som boot-media och skriver mot den så lite det går.

varken SD-minne eller USB-stickor kan anses som pålitlig lagringsmedia idag...

[1]

När man skrev 'sync <enter> ' första gången så fick man tillbaka promten omedelbart igen och man visste inte om jobbet var klart, därför skrev man snabbt 'sync <enter>' en gång till då om den första 'sync' inte ännu var klar så kunde den påföljande 'sync' inte köras och promten var borta till sync-processen verkligen var klar!.

En väg är att med en permanent OTP-programmering göra att det alltid bootar från USB istället för SD-minne och du slipper den ömtåliga SD-minnet.

Det är bara att söka så finns det ett antal guider hur man gör detta, det fina är att man kan använda valfri storlek av USB-hårddisk för detta, nackdelen dock är att USB-gränssnittet är inte speciellt snabb och delar dessutom med nätverkskortets trafik (det gör inte SD-minnet) ...

Obs - det är en permanent ändring och det går inte att backa tillbaka till SD-boot igen när den väl är gjord eftersom den programmerar SoC-chippets OTP-minne som hanterar SD, USB och nätverksenheterna.

Nu börja väl tråden bli lite gammal...

Men stötte på ett liknande situation och börja titta lite mer på det.

En sak kan man konstatera att SD-minne är att usla bärare av data - och det är heller inte snabbt.

Farten kan dock vara hyffsad om man skriver större filer sekventiellt (och det är detta SD-korten i första hand är optimerad för - kameralagring av bilder så fort det går)

Men skriver man mer slumpmässigt i småblock (4 kB, som är typiskt minsta blockstorlek i ett filsystem) - då är prestandan urusel rent ut sagt - med riktigt snabb SD-kort typ samsung EVO + på 32 GB (klass U3) så kan man nå runt ~3-4 MB/s på en RPI3B med randomize 4K skrivning, bättre halvan av SD-minne modellerna runt 1-2 MB/s och så kan man råka hitta någon klass 10 kingston som är nere på 0.17 MB/s - det varierar väldigt mycket mellan tillverkare och modell hur de hanterar slumpmässig småblock-skrivning även om alla korten är av class 10-typ och bättre, ju större storlek ju snabbare då mer kan arbeta parallellt på SD-minnet.

Det finns ett program som kallas iozone som kan köra på RPI och kolla på plats med just den SD:n man har, men generell att använda SSD över USB/SATA adapter så får man en faktor 5 ggr högre fart i hantering av slumpmässiga små-post skrivningar.

Efter detta när jag testade så ser det ut som att man bara bör använda SD-kortet som boot och system med så lite skrivande som möjligt och det som är dataintensivt gör man över USB på en SSD-minne. (har inte provat USB-sticka ännu)

Det finns fördel med SSD som inte är matchat med SD och många billigare USB-stickor numera

- SSD levererar inte korrupt data - det blir io-fel istället precis som all magnetlagring och optomedia - man får inga silent error (dvs. omärkligt läst korrupt data) med SSD som man tyvärr kan få på SD-minne och numera också en del på lågkvalitets USB-stickor (samma innehåll i båda med något olika kontroller och av låg-binnat flash-minne som kanske ger upp och/eller ger korrupt data redan efter någon hundratal omskrivningar) - sedan har SSD bättre kvalitet på flash-kretsar, helt annan uthållighet och en wearlevling med helt andra kvaliteer än på USB-stickor/SD-minne vilket gör slitaget mindre vid massiva småskrivningar och databas-hanterande.

mer om detta kan man läsa i:
http://www.pidramble.com/wiki/benchmarks/microsd-cards

inklusive hur man installera och kompilera upp iozone direkt i använda RPIx och andra miljöer.