Datenmenge kritisch für SD-Karte?

  • Ich habe in einem Raspberry Pi 3B eine Sandisk Ultra mit 16GB, die auf 12GB formatiert ist - um das Image auch wieder auf eine 16GB Karte kopieren zu können. Davon sind etwa 8GB verfügbar.

    Ich möchte auf der Karte alle 15 Sekunden ein Bild von einer Kamera speichern. Die Bilder sind zwischen 60 und 250kB, im Schnitt etwa 200kB groß. Bei der Rate werden am Tag etwa 5760 Bilder gespeichert und ergeben etwa 1.1GB. Danach werden die Bilder zu einem Video verrechnet, ergeben dabei noch etwa 20-30MB, und werden nach dem Erstellen des Videos gelöscht.

    Die Videos werden nach 30 Tagen gelöscht.

    Das ergibt eine Datenmenge von 33GB Bilder + 1GB Videos pro Monat. In 3 Jahren etwa 1.2TB an Daten. Die verfügbaren 8GB der Karte werden dabei etwa 150 mal neu beschrieben.

    Preisfrage: Sind diese Datenmengen über diesen Zeitraum problematisch für die SD-Karte, oder steckt die das locker weg?

    Ja, natürlich kann so eine Karte individuell ausfallen, und von der Karte werden auch mehr oder weniger regelmäßig Backups gemacht. Mir geht es darum: Kann man das so machen oder verstößt das gegen die Genfer Konventionen zum Schutz von SD-Karten?

  • Sind diese Datenmengen über diesen Zeitraum problematisch für die SD-Karte, oder steckt die das locker weg?

    Nicht die Datenmenge ist das relevante, sondern die Anzahl der P/E-Zyklen... also die Anzahl der Schreib- und Löschvorgänge. Ich wäre nicht im geringsten überrascht, wenn die Karte nur wenige Wochen oder Monate überlebt.

  • Naja, bei der Datenmenge wären das eben gleichmäßig auf die Karte verteilt - ein einigermaßen intelligentes System vorausgesetzt - etwa 150 Schreib / Löschzyklen für jeden Speicherblock in 3 Jahren.

  • Wenn du das sogenau weißt, wo liegt das Problem? Kannst uns nach 3 Jahren ja mitteilen, ob deine Berechnung richtig war.

  • So kann man das nicht rechnen.... da fehlen etliche Aspekte:

    • Ist die Karte nicht mit noatime gemountet, wird bei jedem Zugriff die Access-Time geschrieben
    • Bei jedem Schreibvorgang wird die Inode-Tabelle geändert
    • Ob der Kernel die Inode-Tabelle cached und nur einmal schreibt oder immer jede Änderung sofort, sollte auch berücksichtigt werden
    • Mit jedem Schreibvorgäng sinkt die Data-Retention der Zelle
    • Beim Wearlevelling werden immer auch Datenblöcke einbezogen, die sich nicht geändert haben, damit es zu einer vergleichmäßigten Beanspruchung kommt
    • Sogar ReadOnly-Blöcke werden dabei umkopiert, sonst würde es Zellen geben, die nicht beansprucht werden, andere dafür unverhältnismäßig hoch
    • Die SD-Karten-Spezifikation enthält keine Einträge für Wearlevelling
    • Ob Wearlevelling von der Karte unterstüzt wird, sollte also explizit vom Hersteller angegeben sein
    • Das Phänomen Read Disturb kann sich nach einiger Zeit als zusätzliches Problem erweisen. Um das zu vermeiden werden auch wieder Blöcke umkopiert.
    • Die Umgebungstemperatur verschlechtet maßgeblich die Data Retention... also in Relation zu den P/E-Zyklen

    Ich denke, probiers einfach... ich würde das nur so ausgestalten, dass es sich im Fall der Fälle nicht zu Schaden auswirken kann und ich wäre nicht überrascht, wenn die Karte binnen 6 Monate tot ist.

    Ich mache das gleiche, ebenfalls 4000-5000 Bilder am Tag, aber ich habe mir dafür einen Banana PI M3 geholt, der das komplett im RAM macht und die Daten im 5-Minuten-Zyklus auf einen FTP-Speicher überträgt. Alle Bilder im RAM, die älter als 12 Stunden sind, werden im 4 Stunden-Rhythmus gelöscht. Das heisst, 12 Stunden liegen direkt vor, alles ältere gepackt, verschlüsselt und auf den FTP-Server im Web gesichert.Auf dem FTP-Server werden täglich einmal alle Pakete älter als 24 Stunden gelöscht. Also... wie gesagt... probiers einfach.....

  • ... der das komplett im RAM macht und die Daten im 5-Minuten-Zyklus auf einen FTP-Speicher überträgt...

    Das wäre halt mein Plan B: Die Bilder auf Ramdisk, und dann alle 3 Stunden ein Video mit avconv erstellen und die Bilder löschen. Dann die Videos eines Tages zusammenfassen. Muss mal sehen, ob avconv das kann.

    Ist aufwendiger, deswegen hätte ich mir das gespart wenn die Meinung dahin geht: Die paar GB machen der SD-Karte gar nix, das kann die auch 20 Jahre lang ab...

  • Was mir beim Lesen als erstes in den Sinn gekommen ist: Warum arbeitet man nicht mit einem USB-Stick - oder zwei? Soweit ich mich erinnern kann hat ein (guter) USB Stick deutlich mehr Schreibzyklen, oder? Vor allem wäre bei einem Defekt nicht das System betroffen, sondern nur der "zwischenspeicher". Am zweiten USB Stick könnte man die Videos speichern, damit diese im Falle eines Crashs auch gute "Überlebenschancen" haben...

    ...wenn Software nicht so hard-ware ;) ...

    Freue mich über jeden like :thumbup:

    • Offizieller Beitrag

    Hallo,

    meine Antwort hat zwar nur mittelbar mit Deiner Frage zu tun, aber

    Ich habe in einem Raspberry Pi 3B eine Sandisk Ultra mit 16GB, die auf 12GB formatiert ist - um das Image auch wieder auf eine 16GB Karte kopieren zu können.

    sieh Dir dazu mal Image verkleinern mit pishrink an. ;)

  • Warum arbeitet man nicht mit einem USB-Stick - oder zwei?

    Was unterscheidet die NAND-Speichertechnik eines USB-Sticks von der NAND-Speichertechnik einer SDC? Ich denke mal, absolut gar nix. Die relevanten Unterschiede würde ich im Controller vermuten, der beim USB-Stick wahrscheinlich ein deutlich besseres Speichermanagement betreibt und dadurch eine scheinbar längere Lebensdauer "rausholt". Aber die Mängel bezogen auf die Speicherzellen in Relation zu den P/E-Zyklen bewerte ich als gleichrangig. Ich bin der Meinung, NAND-Speicher-Geräte sind für solche Zwecke generell ungeeignet. Und der Grad der Eignung fällt weiter signifikat in direkter Abhängigkeit von der Häufigkeit des Schreibens und der Wichtigkeit der Daten. Bei hoher Schreibhäufigkeit und wichtigen Daten sind m.E. alle NAND-Speicher ein absolutes NoGo.Ich würde z.B. einem NAND-Speicher definitiv keine Backups anvertrauen. Aber das ist nur meine Meinung... da muss ein jeder seine eigenen Erfahrungen machen ... also einfach mal machen....

  • Das wäre halt mein Plan B: Die Bilder auf Ramdisk, und dann alle 3 Stunden ein Video mit avconv erstellen und die Bilder löschen. Dann die Videos eines Tages zusammenfassen. Muss mal sehen, ob avconv das kann.

    Wenn es sich um Überwachungs-Cams handelt, halte ich 3 Stunden für viel zu lang. Und vor allem, wenn die Aufnahmen nur im RAM gespeichert sind. Bei mir werden nach Move-Detection-Events regelmäßig unmittelbar die letzten 5 Minuten weggesichert.... ein Paket packen und verschlüsseln, Paket in die (Inventar-)Liste eintragen, Paket versenden. Täglich Nachts alte Pakete aus der (Inventar-)-Liste auf dem Web-Space löschen. Das ist hier ein unendlicher Kreislauf, der völlig wartungsfrei läuft und immer mindestens die letzten 24 Stunden vorhält.

    j.m.2.c.

  • Ich habe im Auto seit ca. 4 Jahren eine Dash-CAM.

    Diese schreibt 1 Minuten-Sequenzen bis die Karte (Micro-SD, 32GB, Sandisk extreme) voll ist und überschreibt dann die älteste Aufzeichnung.

    Die Karte reicht, um ca. 3h Video aufzuzeichnen.

    Ich fahre pro Werktag (220 Tage/a) ca. 1:10-1:40h (Fahrt zur Arbeit und zurück).

    D.h., die Karte wird ca. alle 2,5 Tage komplett überschrieben (Urlaubs- und andere Fahrten mal nicht berücksichtigt).

    Die Karte bekommt also pro Jahr 88 Komplettfüllungen, macht 32GB * 88 = 2816 GB/a.

    Nun, die Karte läuft immer noch... ich rechen ja inzwischen damit, dass die demnächst nicht mehr will, schau allerdings nur 1x im Monat, ob sie noch tut, ansonsten ist mir die Aufzeichnung ja egal...

    ich denke, du solltest mit einer "besseren" Karte wenig Probleme haben...

  • Warum arbeitet man nicht mit einem USB-Stick - oder zwei?

    Ja, kann man auch machen - wenn denn die Karte ein Problem wäre. Deswegen ja meine Frage, sind die Datenmengen üblicherweise ein Problem oder kann eine gute Karte das locker ab?

    Wenn es sich um Überwachungs-Cams handelt, halte ich 3 Stunden für viel zu lang.

    Nicht in dem Sinne. Damit werden die Hunde "überwacht", so dass man sehen kann, was die so treiben, wenn man nicht da ist. Und ein Teil der Wiese wird "überwacht", so dass man sehen kann was sich so rumtreibt.

    MotionDetection wäre vielleicht für die Wiese eine Option, für die Hunde nicht, da soll es ein Zeitraffer-Video sein. Würde sonst zu ungleichmäßig laufen und zu oft ansprechen.

    Ist also nicht schlimm, wenn mal ein paar Stunden fehlen würden. Viel bescheidener ist, dass sich die Kameras auch mal aus dem Wlan ausklinken oder vom Router rausgeworfen werden.

  • Und um die Technik richtig zu stellen...

    nicht lesen und schreiben sind das Problem...

    einzig der Löschvorgang "beschädigt" das Substrat ! hierfür wird kurzzeitig eine höhere Spannung angelegt, die die Zellen löscht.

    Insofern : Viel Schreiben bedingt natürlich auch viel Löschen!

    @ Zentris Deine Karte macht also im Idealfall pro Jahr nur 88 Löschungen ... das ist sozusagen gar nichts ;o))

  • Ich dachte, der Unterschied zwischen normalem löschen und schreiben wäre, das beim Schreiben Daten auf dem Datenspeicher gespeichert werden und beim Löschen nur der Eintrag im Dateisystem entfernt wird.

  • Ich dachte, der Unterschied zwischen normalem löschen und schreiben wäre, das beim Schreiben Daten auf dem Datenspeicher gespeichert werden und beim Löschen nur der Eintrag im Dateisystem entfernt wird.

    Musst Du unterscheiden: Beim "Löschen" der Datei wird nur der Eintrag entfernt. Die Daten stehen weiterhin im Flash. Soll allerdings diese Stelle wieder genutzt werden, muss sie vorher physisch gelöscht werden.

    Initial sind alle Bits gesetzt: 0xFF.

    Beim Schreiben werden die Bits, die im zu schreibenden Wert Null sind, geleert: 0xAA. Das schadet dem Flash nicht.

    Beim "Löschen" bleiben die Bits stehen: 0xAA

    Wird diese Speicherstelle erneut beschrieben, müssen die Bits vorher wieder gesetzt werden: 0xFF. Das ist der Vorgang, der den Flash schädigt.

    Und dann kann der neue Wert gespeichert werden, in dem die Null-Bits geleert werden: 0xBB

    Aber ja, natürlich schadet das Verwalten der Speicherkarte dieser auch. Weiss nicht, wie ext4 das handhabt.

  • @ Zentris Deine Karte macht also im Idealfall pro Jahr nur 88 Löschungen ... das ist sozusagen gar nichts ;o))

    Ja, genau:

    Der TO hat in 3 Jahren mit 150 Neubeschreibungen (8GB-Karte) kalkuliert.

    Mein CAM kommt in 3 Jahren auf 264 Neubeschreibungen...

    Insofern ist die Schreibleistung beim TO geringer... insofern sollte ein gute Karte recht lange halten (Wobei eine 16/32GB Karte noch besser wäre, wegen der Verteilung der Schreiblast (siehe unten)).

    Was bei der CAM verschärfend hinzu kommt:

    Die CAM schreibt die gesamte Karte immer komplett voll bzw. hat immer eine volle Karte, der TO wird immer nur einen Teil der Karte beschreiben.

    Da der SD-Speicherkontroller die Schreibzugriffe auf die gesamten 8GB verteilen kann, ist die Schreiblast für eine einzelne NAND-Zeile geringer als beim Einsatz in der CAM...

  • Bei meinem root-Filesystem (EXT4) wird beim Löschen einer Datei nur dessen I-Node inhaltlich gelöscht und die Inode-Nummer in die Inode-Freelist gestellt. Die Daten in den Sektoren bleiben erhalten, nur die Sektoren werden in der Block-Bitmap als frei markiert.

    Daneben wird aber diese Aktion minutiös ins Journal protokolliert, womit auch ein "undelete" der gelöschten Files ermöglicht wird. Beim Löschen finden daher mehrere Schreibzugriffe auf die Metadaten des Filesystems statt. Nur die Daten des Files selbst bleiben unberührt.

    Mit < dumpe2fs /dev/DeineRootpartition > ist die Metadatenverwaltung des Ext4 Filesystems auch human readable einsehbar.

    Inder Grundkonfiguration eines EXT4 Filesystems finden jede Menge Schreibzugriffe auf die Metadaten (in Gruppe 0 und 1) statt und das immer im selben Bereich. Und dort wird IMHO eine SD defekt. Deshalb finde ich es nicht sinnvoll auf der root-Partition derart viele Schreib- ind Löschoperationen durchzuführen (sondern auf einer eigenen Partition).


    Servus !

    RTFM = Read The Factory Manual, oder so

  • und das immer im selben Bereich. Und dort wird IMHO eine SD defekt. Deshalb finde ich es nicht sinnvoll auf der root-Partition derart viele Schreib- ind Löschoperationen durchzuführen (sondern auf einer eigenen Partition).

    Nein:

    Das installierte Filesystem hat mit der Datenablage auf der SD-Karte nichts zu tun:

    Quelle: https://www.thalia.de/shop/home/arti…ProvID=11000523


  • Musst Du unterscheiden: Beim "Löschen" der Datei wird nur der Eintrag entfernt. Die Daten stehen weiterhin im Flash. Soll allerdings diese Stelle wieder genutzt werden, muss sie vorher physisch gelöscht werden.

    Das meine ich doch auch. Das beim Schreiben vorher gelöscht werden muss ist eine Flash Eigenart. Bei Festplatten ist das, soweit mir bekannt, nicht nötig. Deinem Beispiel kann ich allerdings nicht folgen. Das verwirrt nur. :)

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!