SD-kortet har hyss för sig?

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

SD-kortet har hyss för sig?

Har nån här upplevt att SD-kortets funktion tillsammans med fopen/fclose och de vanliga fprintf/fscanf kan vara sämre?
Jag har en del oförklarliga fenomen när jag skriver till SD-kortet och jag har granskat koden och kan inte se några fel.
Har gjort logg på returvärdet på samtliga ingående funktioner och ser inga fel.
Jag begriper inte.
Nu lägger jag över de filerna till RAM-disk och testar där. Filerna är flyktiga ialla fall så det spelar ingen roll.
Men vill gärna höra era erfarenheter av filhantering (av många filer) på ett SD-kort.

Trädvy Permalänk
Medlem
Plats
Östersund
Registrerad
Jan 2010

Du skulle ju kunna börja med att försöka förklara lite istället, just nu är det mest en flum av information.

Vilken enhet? Exakt modell på SD kort?
Vad menar du med "kan vara sämre"? sämre än vad? Sämre än pannkaka?
Vilka oförklarliga fenomen?

Min erfarenhet av många filer och SD-kort är att Sirap i -20c är troligen snabbare på att ta sig fram. Men jag har också billiga skit kort som jag köpte på Ica.

Maximus X Hero - 8700k @5.1GHz - H115i - 32GB LPX@3466MHz - MSI 980Ti Gaming - EVGA SuperNova 750 G2 - Asus vg248qe - FD R5

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Det är svårt att förklara och "informera" mest på grund av problemet uppträder i funktioner som fungerar felfritt men vid intensiv användning av dessa funktioner så börjar filer på SD-kortet att vägra skriva om sig. När jag startar om programmet så fungerar det igen - EN gång. Sen inte mer (vid intensiv användning av funktionen som skriver på SD-kortet). Jag fick då en aning om att stängningen av filen inte fungerade så att NÄSTA användning av filen inte blev riktig. Lade in error-utskrifter och kollade retur-värden men det gav ingenting från vare sig fopen eller fclose.
Det var då jag började misstänka SD-kortet (som är av känt märke).
Så det är en "känsla" jag har. En "känsla" av att det kan vara nåt utanför koden som spökar. Därför ställer jag en fråga här om andra har upplevt att kortet inte alltid uppför sig korrekt. Speciellt vid intensiv skrivning.

Trädvy Permalänk
Medlem
Registrerad
Apr 2012

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 ??

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016

Frågan kanske skulle ha varit "Måste man handskas annorlunda med skriv/läs av filer på ett SD-kort relativt vanlig hårddisk?". Jag tänker då inte på antalet skrivningar/läsningar utan mer på om det måste till extra delayer efter stängning av filer eller annan form av "specialbehandling".

Trädvy Permalänk
Avstängd
Plats
som gud är min närvaro överallt.
Registrerad
Nov 2005

@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

Om du lär dig älska din smärta kommer du känna dig älskad var dag;-)

main dator: rampage v10, 6950x, Titan xp,64gig ram,intel 950,2x 10gig nic, asus 2k 165hz ips skärm, 900D custom vattenkylning.
main server: Supermicro, amd 6386se 16 trådar, 20TB i raid 6, 64gig ecc ram, 6x 10 gig nic. custom vattenkylning. 1/1gig nätverk via dedikerad fiberlina, router:usg pro4

Trädvy Permalänk
Medlem
Plats
Östersund
Registrerad
Jan 2011
Skrivet av Sweedland:

Frågan kanske skulle ha varit "Måste man handskas annorlunda med skriv/läs av filer på ett SD-kort relativt vanlig hårddisk?". Jag tänker då inte på antalet skrivningar/läsningar utan mer på om det måste till extra delayer efter stängning av filer eller annan form av "specialbehandling".

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.

CPU: i7 4770k Noctua NH-D14 MOBO: Maximus VI Hero GPU: GTX 980 RAM: 16 GB 1600 MHz Chassi: R4 PSU: Corsair AX860 Hörlurar: SteelSeries 840 Mus: Logitech G500s V.v. citera mig för att få svar.

Trädvy Permalänk
Medlem
Registrerad
Jun 2011

Provat att byta SD-kortet? Jag hade problem med min rock64 enkortsdator, trodde jag, men var i själva verket sd-kortet som förlorade bits eller något. klass 10? javisst.. men ändå krashar OS:et och startar inte mer. Efter att ha provat att skriva X avbild och kolla differens mellan avbild och läsning så kom det fram att kortet tappar data. ibland fungerade det, ibland inte.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av aragon:

@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

Aragon. Det är SD-kortet till Raspberry:n. Sorry. Lade tråden under enkortsdator men missade detaljen med RPi.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av swehunter2000:

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.

Exakt. Jag hade velat ha mer kontroll på själva skrivningen också. Inte nöja mig med fclose() bara.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av Whaleboobs:

Provat att byta SD-kortet? Jag hade problem med min rock64 enkortsdator, trodde jag, men var i själva verket sd-kortet som förlorade bits eller något. klass 10? javisst.. men ändå krashar OS:et och startar inte mer. Efter att ha provat att skriva X avbild och kolla differens mellan avbild och läsning så kom det fram att kortet tappar data. ibland fungerade det, ibland inte.

Ska testa att byta SD-kort. Det är ju tråkigt att "Klass 10" kort också ger problem. Det är lite svajjigt.
Jag undrar om jag inte blir i förlängningen tvungen att ersätta SD-kortet med nåt annat....

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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!.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

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!.

Då måste jag fråga; Kan det vara vettigt att skriva fflush(stream) före fclose() (fflush(NULL) flushar alla öppna filer) ? Som i PHP kan man ju skriva flush() för att tömma bufferten....

Edit:
"Note that fclose() flushes only the user-space buffers provided by the
C library. To ensure that the data is physically stored on disk the
kernel buffers must be flushed too, for example, with sync(2) or
fsync(2)."

Jag tror jag ska använda mig av ramdisk till de filer som används intensivt. Endast en del av dessa filer ska sammanställas och sparas för eftervärlden.
Ska testa detta under veckan. Senare får jag fundera på SSD för den "operativa delen" och ha enbart SD för boot.

Man-pages
Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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.

Trädvy Permalänk
Medlem
Registrerad
Aug 2016

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.

Trädvy Permalänk
Medlem
Plats
Dalarna
Registrerad
Apr 2016
Skrivet av xxargs:

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

Tråden kanske är gammal men inte ämnet. Tack för informationen. Ska prova ditt förslag.
Det gör att SSD måste nog på sikt hamna i BOM:en.