Werde mich kurz halten, möchte Informationen alle xyz Milli Sekunden speichern, schreiben und lesen etc... jetzt frage ich wie hoch die Gefahr von SD Card Korruption?
Nor schrieb: > Werde mich kurz halten, möchte Informationen alle xyz Milli > Sekunden > speichern, schreiben und lesen etc... jetzt frage ich wie hoch die > Gefahr von SD Card Korruption? Wenn du immer an der selben Stelle Schreibst, wird sie das vermutlich nicht mögen. Brauchst du die Daten dauerhaft (auch nach dem Ausschalten)? Wenn nicht, richte dir eine RAM-Disk ein.
Nor schrieb: > möchte Informationen alle xyz Milli Sekunden speichern, schreiben Dann brauchst du eine Festplatte oder wenigstens eine "richtige" SSD. SD Karten sind dazu nicht geeignet. > jetzt frage ich wie hoch die Gefahr von SD Card Korruption? Sehr hoch.
Nor schrieb: > alle xyz Milli Sekunden > speichern, schreiben und lesen Das geht mit SSD aber nicht mit SD Karten. Letztere tauchen schon mal >300ms zum Schreiben eines Blocks ab. Außerdem vertragen SD Karten nicht allzuviele Schreibzyklen.
Nor schrieb: > Werde mich kurz halten ... Die Zeit für vollständige Sätze solltest du dir trotzdem nehmen.
Lege dazu zwei extra-Partitionen an. Eine für Swap und eine für die Daten. Wenn die Karte korrumpiert, sind die bisherigen Daten meist zu retten. Um ab und zu eine Sicherungskopie auf ein anderes Medium, kommst Du aber nicht herum.
Dieter schrieb: > Lege dazu zwei extra-Partitionen an Halten SD Karten die Daten der Partitionen voneinander getrennt? Ich hätte erwartet, dass das Wear Levelling sie letztendlich wieder schön durcheinander würfelt.
STK500-Besitzer schrieb: > Brauchst du die Daten dauerhaft (auch nach dem Ausschalten)? Wenn nicht, > richte dir eine RAM-Disk ein. Genau. Würde ich auch empfehlen. Alles was nur kurzzeitig gebraucht wird, auf Ramdisk. Bringt auch noch einen deutlichen Geschwindigkeitsvorteil.
STK500-Besitzer schrieb: > Wenn du immer an der selben Stelle Schreibst, wird sie das vermutlich > nicht mögen. > Brauchst du die Daten dauerhaft (auch nach dem Ausschalten)? Wenn nicht, > richte dir eine RAM-Disk ein. Tatsächlich sollten die Daten bestehen nach einem Neustart. Sie werden hauptsächlich zur Auswertung und Visualisierung verwendet. mfg
Die SSD überleben auch nicht. Wieso trickst du nicht einfach. ??? Legen die Daten in einen Datenblock im Ram ab. Und schreibe den Datenblock alle X -MINUTEN auf eine SSD. Was deiner Frage angeht, die kannst du dir ausrechnen sogar. Die Hersteller geben alle die maximale Beschreibbarkeit an. Also 10 Std. / 300 ms = SD TOT. 200 Std. / 300 ms = SSD tot. Davon abgesehen wage ich zu bezweifeln das die SD / SSD überhaupt so schnell ist auf Dauer. Ist halt ne Frage des Datenblocks. Und Zwischenpuffer ist das nicht machbar. Der Meinung bin ich. Gruß Pucki
Nor schrieb: > Tatsächlich sollten die Daten bestehen nach einem Neustart. Alexander K. schrieb: > Legen die Daten in einen Datenblock > im Ram ab. Und schreibe den Datenblock alle X -MINUTEN auf eine SSD. Genau. Ich habe eine Anwendung, die jede Minute ca. 120 Zeichen in eine Textdatei auf SD Karte schreibt. Die Karte ist jetzt 1,5 Jahre im Einsatz und noch gut. Vermutlich puffert das Linux die Schreibzugriffe ohnehin. Nur weiß ich nicht, wie lange und inwiefern man sich darauf verlassen kann. Mit einem Puffer innerhalb der Anwendung würde ich mich wohler fühlen.
Nor schrieb: > Tatsächlich sollten die Daten bestehen nach einem Neustart. Du könntest auf log2ram aufsetzen (https://github.com/azlux/log2ram). Das wird sehr häufig und gerne bei Raspberry bzw. in Verbindung mit sdcard genommen. Primär wurde es für das /var/log gedacht. Beim Herunterfahren wird es komplett zurückgeschrieben, ebenso beim Start komplett eingelesen. Oder du richtest eine RAM-Disk ein und mountest sie für das entsprechende Verzeichnis bzw. eine einzelne Datei. Stichwort: swap in a file
Stefan ⛄ F. schrieb: > Genau. Ich habe eine Anwendung, die jede Minute ca. 120 Zeichen in eine > Textdatei auf SD Karte schreibt. Die Karte ist jetzt 1,5 Jahre im > Einsatz und noch gut. Ja, die schreibt mit APPEND-Befehl. Was bedeutet physikalisch wird immer DIE NÄCHSTE Speicherstelle belastet. Da klappt das logoweis Jahre lang. Irgendwann ist die Karte voll. Die Datei wird gekillt und der "Schreibzähler für die Belastung der Karte um ein erhöht". Das geht klor noch Jahre lang. Aber nur wegen den APPEND-Befehl. Der schützt nämlich die anderen Stellen. Davon abgesehen schreibt du JE Minute und nicht alle 300 mS, was bedeutet ca. 200 Schreibzugriffe in einer Minute nicht nur einen. Expotenziales (oder wie man in der Schule sagte "hochrechnen") führt dann nämlich zu gigantischen Werten. Wenn die SD nun noch wie üblich FAT-32 Formatiert ist .... ;) Packe sie gar nicht er aus, schmeiß sie gleich weg oder schicke sie mir ;) Gruß Pucki
Ach so nebenbei. Ich benutzt eine 64 GB (mirco)-SD-Karte in meinen DVD-Festplatten-Recorder als Ersatzfestplatte. Hat mich 16 Euro gekostet das Teil. Ich gebe ihr eine Lebensdauer von 1-2 Jahren. Da rechnet sich prima. Keine Kühlung, Weniger Energieverbrauch und vor allen keine Geräusche. Das alles bezahle ich halt mit der niedrigeren Lebensdauer der Karte. Gruß Pucki
Ich häng' mich mal mit an den Thread. Hat jemand Erfahrung mit diesen SD-Karten? https://www.westerndigital.com/products/embedded-removable-flash/surveillance-sd-microsd-cards bis zu 768TBW klingt nicht schlecht. Ich frage mich, ob das nur bei sequenziellem Schreiben gilt, da ausschliesslich Video als Anwendungsbereich angegeben ist.
Alexander K. schrieb: > Stefan ⛄ F. schrieb: >> Genau. Ich habe eine Anwendung, die jede Minute ca. 120 Zeichen in eine >> Textdatei auf SD Karte schreibt. Die Karte ist jetzt 1,5 Jahre im >> Einsatz und noch gut. > > Ja, die schreibt mit APPEND-Befehl. Was bedeutet physikalisch wird immer > DIE NÄCHSTE Speicherstelle belastet. Da klappt das logoweis Jahre lang. > Irgendwann ist die Karte voll. Die Datei wird gekillt und der > "Schreibzähler für die Belastung der Karte um ein erhöht". Gilt das nur, wenn die 120 Bytes jedesmal angehängt werden oder auch wenn die 120 Bytes in einer 120 Byte großen Datei jedesmal überschrieben werden (z.B. in C)?
Hans Dampf schrieb: > Gilt das nur, wenn die 120 Bytes jedesmal angehängt werden oder auch > wenn die 120 Bytes in einer 120 Byte großen Datei jedesmal überschrieben > werden (z.B. in C)? Wenn du überschreibst, wird ja die Zelle neu belastet. Wenn du anhängst, wird eine "neue" Zelle belastet. Das führt dazu das alle Zelle gleichmäßig belastet werden. Ich wage sowieso zu bezweifeln das SD - Karten so ein guten Zellen-Managment haben wie SSD. Da sorgt eine schlaue Elektronik für eine gleichmäßige Ausnutzung der Zellen. Zellen = Speicherzellen Gruß Pucki
Alexander K. schrieb: > Ja, die schreibt mit APPEND-Befehl. Was bedeutet physikalisch wird immer > DIE NÄCHSTE Speicherstelle belastet. Da klappt das logoweis Jahre lang. Das ist dann doch zu stark vereinfacht. Vielleicht wäre hier etwas know-how hilfreich, was tatsächlich passiert, wenn man "ein paar Bytes anhängt". Es gibt Verwaltungstrukturen im Filesystem (z.B. inodes, bitmaps, fat, ...): welche Blöcke sind benutzt, wann wurde zuletzt geschrieben, wie groß ist die Daten, welche Blöcke gehören zur Datei etc. Diese werden bei jedem Schreibzugriff aktualisiert und liegen bei einer Datei immer auf denselben Blöcken. Die Abnutzung dieser Blöcke ist daher ein vielfaches höher als die der eigentlichen Nutzdaten. Deine Strategie geht zwar in die richtige Richtung, wird aber ohne weitere Maßnahmen so nicht funktionieren. Dagegen helfen nur Wear-Leveling und bestimmte Flash Filesystem die dies mitigieren. Alternative: man allokiert den Speicher selbst und macht das block management selbst. Dazu legt man ganz am Anfang eine große Datei an, man verzichtet auf die Aktualisierung der Meta-Daten und sucht sich nach einem Neustart die Schreibposition selbst wieder. Die meisten SD Karten Hersteller machen bei ihren Karten ein Geheimnis daraus, ob und falls ja wie gut die verwendeten Wear Leveling Algorithmen und das dazu benötigte over-provisioning ist. Von SanDisk gibt es verschiedene Qualitäten und die hochwertigen Karten haben sicher ein Wear Leveling, bei den billigeren ist das nicht garantiert. Es gibt auch spezielle Industrial Varianten die mittlerweile bezahlbar sind. Dummerweise gibt es bei SD-Karten keinen Trim Befehl wie bei SSDs, d.h. die Karte kann nicht wissen, ob einmal beschriebener Block aktuell noch benötigt wird. Dies schränkt das Wear Leveling weiter ein. Ob das offizielle Tools der SD-Card Association zum Formatieren der Karten die interne Allocation Table zurücksetzt kann man nur hoffen, aber das verwendet ja sowieso niemand. Ich habe hier 2 Transcend Karten liegen, die nach ca. 2 Jahren nur noch lesbar aber nicht mehr beschreibbar sind. Wurden in einem Raspi verwendet der ausschließlich einen ntp Server laufen hat verwendet mit intensivem ntp Logging, d.h. ca. 5 Logfiles wurden jede Sekunde geschrieben. Mit Sandisk Ultra Karten hatte ich bisher weniger Probleme. Will heißen: kaufe vernünftige SD Karten, das reduziert die Probleme oder noch besser nimm eine SSD, die hat ein gutes wear leveling. Michael
:
Bearbeitet durch User
Nor schrieb: > Tatsächlich sollten die Daten bestehen nach einem Neustart. Sie werden > hauptsächlich zur Auswertung und Visualisierung verwendet. mfg Wenn dein Gerät auch sauber heruntergefahren wird (was ja eigentlich immer so sein sollte, dann könnte man den Inhalt der RAM-Diak abeim Runterfahren auf die SD-Karte schreiben. Das müsste mit einem rc-Level gehen, oder?
Ganz andere Idee: Du benutzt den 40-poligen Header und schließt ein externes FRAM oder ein batteriegepuffertes SRAM per SPI oder I2C an und benutzt das als temporären Datenspeicher. fchk
Ich schreibe jede Minute die Daten meiner Haussteuerung auf eine Sqlite3-DB auf der Ramdisk /dev/shm. Jeden Tag um 0:01 Uhr werden die Daten der letzten 24 Stunden an die Jahres-DB im normalen Filesystem angehaengt und die aeltesten Daten von der Ramdisk-DB geloescht. Das funktioniert seit Jahren. Beim Herunterfahren werden die Daten der Ramdisk-DB vorher an die Jahres-DB ahgehaengt (sofern sie dort noch nicht vorhanden sind). Beim Start wird die Ramdisk-DB mit den Daten der letzten 7 Tage wiederhergestellt. Die Jahres-DB ist ca. 50 MB gross, wenn das Datum den 31.12.erreicht hat, die Ramdisk-DB ist etwa 1 MB gross, bei 250 MB Ramdisk kein Problem. wendelsberg
steck doch einfach einen usb stick an den raspi, puffer die daten für z.b. 30 sekunden und schreib die dann auf den stick. am raspi (wenn er lange laufen soll) mounte ich / i.a. ro und /var rw von einem usb stick.
maler und landstreicher schrieb: > steck doch einfach einen usb stick an den raspi Es gibt mindestens folgende Qualitätsklassen von Flash Speicher mit fallender Qualität: 1. SSD 2. SD-Card 3. USB Sticks Sprich es ist deutlich besser eine SD-Karte als einen USB Stick zu verwenden. Michael
:
Bearbeitet durch User
maler und landstreicher schrieb: > steck doch einfach einen usb stick an den raspi Das Problem: Wie bei SD Karten weiss man auch da nie, wie gut das Wear Levelling implementiert ist. USB Sticks haben da einen ebenso schlechten Ruf. Auch dort gibt praktisch kein Hersteller irgendwelche konkreten zahlen an.
Es gibt z.B. folgende SD-Cards, die für den Zweck geeignet sein sollten: - SanDisk MAX ENDURANCE microSD-Karte 32GB (lange Lebensdauer, bis zu 120.000 Stunden aufnehmen), 16,99 Euro - SanDisk High Endurance microSD Karte 32GB (bis zu 20.000 Stunden aufzeichnen können), 9,99 Euro
Michael D. schrieb: > bis zu 120.000 Stunden aufnehmen > bis zu 20.000 Stunden aufzeichnen Ich liebe solche Angaben. Das ist so unkonkret - hätte man auch gleich weg lassen können.
Stefan ⛄ F. schrieb: >> bis zu 120.000 Stunden aufnehmen > > Ich liebe solche Angaben. Das ist so unkonkret - hätte man auch gleich > weg lassen können. Dann beschwer dich beim Hersteller, dass konkrete Informationen so schlecht zu finden sind. Links mit den Datasheets sind gerne gesehen. Ich nehme die "120.000 Stunden" Aussage als "ist langlebiger als die 20.000 Stunden Karte vom gleichen Hersteller". /Edit: Die 20.000h gelten laut einen anderen Prospekt natürlich nur für die 256 GB Variante, bei 32 GB bleiben noch 2.500h übrig :-) https://documents.westerndigital.com/content/dam/doc-library/en_us/assets/public/sandisk/product/memory-cards/high-endurance-uhs-i-microsd/data-sheet-high-endurance-uhs-i-microsd.pdf Michael
:
Bearbeitet durch User
Ich würd ’ne ganz andere Karte nehmen. Diese sind offensichtlich nur für sequentielles Schreiben bei einer festen Bitrate gedacht; bei Karten für den allgemeinen Gebrauch wird besser die Datenmenge angegeben, die typischerweise geschrieben werden kann. Natürlich gibt’s da auch Faktoren, die’s teils um das Mehrfache daneben liegen lassen (1GB am Stück geschrieben wird die Karte erheblich weniger belasten, als 1000 1MB-Files hintereinander), aber es ist zumindest sinnvoller, als ’ne „Aufzeichnungsdauer“ ohne weitere Parameter – die sagt mal nämlich überhaupt nix. Michael D. schrieb: > Sprich es ist deutlich besser eine SD-Karte als einen USB Stick zu > verwenden. Das entspricht nicht meiner Erfahrung. Tatsächlich kann’s heute gar vorkommen, dass man einen Stick aufmacht, und eine μSD-Karte fest eingebaut vorfindet. Bei billigen Anbietern aus Shenzen Hinterhof kann’s auch passieren, dass man im Stick Speicherchips findet, die aus alten Smartphones stammen. Auch gibt’s Sticks, deren Controller ähnliche Eigenschaften aufweist, wie der eines SSDs – so pauschale Aussagen sind jedenfalls in der Regel falsch.
Jack V. schrieb: > Ich würd ’ne ganz andere Karte nehmen. Mach's nicht so spannend, nenn einfach den Hersteller, Typ und die Daten dazu. Michael
Michael D. schrieb: > Mach's nicht so spannend, nenn einfach den Hersteller, Typ und die Daten > dazu. Das Problem ist: wenn man nach zwei Jahren sicher sagen kann "Ja, die ist gut, hat sich bewährt", kann man sie schon nicht mehr kaufen.
Michael D. schrieb: > Mach's nicht so spannend, nenn einfach den Hersteller, Typ und die Daten > dazu. Suche ich bei konkretem Bedarf heraus – da weiß ich dann auch, worauf ich Wert lege. Nein, die Aussage war, dass ich, wenn ich wahlfrei schreiben möchte, keine Karte hernehmen würde, die offensichtlich auf sequentielles Schreiben bei einer gegebenen (aber nicht direkt angegebenen) Schreibgeschwindigkeit ausgelegt ist.
Hans Dampf schrieb: > Gilt das nur, wenn die 120 Bytes jedesmal angehängt werden oder auch > wenn die 120 Bytes in einer 120 Byte großen Datei jedesmal überschrieben > werden (z.B. in C)? Daten, die immer wieder überschrieben werden, sind am besten auf einer Ramdisk aufgehoben, egal, wieviele Bytes. Wenn sie nach einem Neustart gebraucht werden, kann man sie beim Herunterfahren oder in bestimmten Zeitabständen auf die SD kopieren.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.