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
Svenstavik
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 @5GHz - 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
Medlem
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
Stockholm
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 DH-14 MOBO: Maximus VI Hero GPU: Nvidia 980 RAM: 16 GB Corsair RAM 1600 MHz SSD: Corsair force GT 120 GB, OC Agility 3 120 GB HDD: WD 2TB Chassi: R4 PSU: Corsair AX860 Ljud: Asus Xonar D2X Hörlurar: AKG K 240 MK II Microfon: Modmic 4 Mus: Logitech G500s Matta: Steelseries QcK Mini Skärmar: en BenQ 22' och en Samsung 19'. 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.