Haltbarkeit von SD Karten - Erkenntnisse, Fakten, Strategien

  • Hallo,


    da SD Karten ja hauptsächlich als Bootmedium im ARM Bereich eingesetzt werden, schreibe ich es mal hier hin.


    heute Nachmittag hatte sich mein System auf dem RPI während eines Upgrades schreibgeschützt und dpkg murrte logischerweise mit Abbruch. Im log fand ich dann einige Meldungen auf Schreibfehler im device mmcblk0p2 (root). Nach einem Reboot konnte ich das Upgrade trotzdem fertigstellen. Nun frage ich mich, wie fit die SD-Karte wirklich noch ist. Auf jeden Fall werde ich jetzt schnellstmöglich ein Image von der Karte ziehen.
    Auf einem Wandboard konnte ich ähnliches Verhalten beobachten. Dort war beim Upgraden das System auch readonly - nach dem reboot war die Karte mausetot - sie wird nicht mal mehr als Medium erkannt.
    Über die Effektivität seines wear leveling schweigt sich ja leider jeder Hersteller aus, smartmonitoring tools greifen auch nicht und so steht man dort im dunklen


    Mir fällt so als Erstes ein, root ins Netztwerk oder auf USB bzw. auf SSD (bei SATA Anschluss) auslagern. Zusätzlich vielleicht noch die Schreibzugriffe minimieren.
    evtl. ext4 auf ordered data mode stellen , ramlog einrichten / ins tmpfs auslagern, sysctl.conf mit:


    Code
    vm.swappiness=0
    vm.laptop_mode=5
    vm.dirty_writeback_centisecs=1500
    vm.dirty_expire_centisecs=1500



    befüllen.


    Nun frage ich mal - wie sind Eure Strategien? welche Erkenntnisse und Fakten habt Ihr zu dem Thema?

  • Ich dachte inzwischen hat jeder schon mal von "SD card corruption" auf dem RPi gehört!? Die Karte ist mit größter Wahrscheinlichkeit völlig in Ordnung. Sie muss nur neu formatiert werden. Der RPi hat ein generelles Problem mit SD-Karten. Beim Übertakten wird es noch schlimmer.


    Root ins Netzwerk geht nicht, weil der RPi ausschließlich von der SD-Karte bootet. Bei OpenELEC/rasplex/... ist es gängige Praxis die sowieso read only Root-Partition auf der SD-Karte zu lassen und die Storage-Partition auf einen USB-Stick auszulagern. Bei USB-Sticks tritt dieses Problem nicht auf und ein schneller Stick gibt einen schönen Boost.


    Näheres kannst du im OpenELEC-Forum nachlesen.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Bei SD-Karten sind defekte Speicherzellen ganz normal - es gibt einen µC, der mehr oder weniger effizient die noch funktionierenden Zellen verwaltet - auf dem 30c3 gab es einen interessanten Talk dazu: https://www.youtube.com/watch?v=CPEzLNh5YIo


    Auf meinem Raspberry Pi logge ich mit journald ins RAM, ansonsten hat der bislang bei geschätzt 3-4 Stunden Laufzeit pro Woche bislang gut ein Jahr mit einer Sandisk SD-Karte und Nutzung von VDR und XBMC überlebt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Bei SD-Karten sind defekte Speicherzellen ganz normal


    Alexander, darum geht es nicht. Es geht darum, dass der RPi in bestimmten Anwendungsszenarien regelrecht das Filesystem zerstört und es deshalb beim nächsten Boot read only gemounted wird.


    Gerald


    HP Proliant MicroServer Gen8, Xeon E3-1230, 12 GB RAM, 3xWD red 2TB im RAID 5, 2xSundtek MediaTV Home DVB-C/T, L4M TWIN-C/T, Ubuntu Server 14.04.1, Plex Media Server
    Samsung UE55H6470

  • Wenn sein Wandboard die Karte gar nicht mehr erkannt hat, scheint da mehr als das Dateisystem kaputt gewesen zu sein.


    Bei der Karte im Raspberry wäre ein fsck an einem anderen PC mit Kartenleser für mich der nächste Schritt, dann sieht man ja, ob das Dateisystem korrumpiert wurde und man kann testen, ob es da auch Schreibfehler gibt.

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Die Karte ist mit größter Wahrscheinlichkeit völlig in Ordnung. Sie muss nur neu formatiert werden


    das würde sicher bei der Karte helfen, die heute Probleme machte. Bei der anderen Karte ist es aber so, das sie in keinem KL mehr erkannt wird. Mir ist da kein Programm bekannt, was (low level) da noch was richten könnte.


    bei Netboot dachte ich an sowas hier --> http://lab.ks.uni-freiburg.de/…rryPI_via_Netzwerk_booten

  • ansonsten hat der bislang bei geschätzt 3-4 Stunden Laufzeit pro Woche bislang gut ein Jahr mit einer Sandisk SD-Karte und Nutzung von VDR und XBMC überlebt.


    speziellen Sandisks Ultra cards wird wohl auch nach gesagt, das sie getrimmt werden können --> http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=19554&sid=298774260e35955f010ba103055b5b0a&start=25

  • Ich nutze auch Rpi mit xbian und SD karte.Übertaktet ist die karte auf defaul werte von xbian,quasi minimal.


    in letzte 9 monate sind bei mir auch 2 karte gestörben(beide male bei xbian update seltsamer weise) die waren nicht mehr zu reten,keiner von systeme wolllte die erkennen(yavdr nicht,Windows mit SD Formater nicht und Mac auch nicht)
    auch digi cam nicht die waren einfach tot.Sandisk übrigens beide.(class 6 und class 8)


    Dritte (class 10) läuft jetzt nur als boot medium xbian ist jetzt auf Usb ausgelagert,sein 2-3 monate läuft es ohne probleme.


    Lösung hab ich auch kein,ist aber wie oben erwennt bekante problem bei Rpi und gängisten distris.


    Daher wird geraten System auf USB stick zum verlagern, wegen schreib zugriffe.


    Werde mich intrresiren wie der verhalten bei Rpi B+ ist mit microsd. Sind die auch so anfällig.


    MfG.Haris

    Meine VDR Spielzeuge VDR1 -Yavdr 0.6*SilverStone SST-M02B-MXR-GIADA MG-C1037SL -Imon Lcd-Imon FB-
    Intel Celeron 1037U*4GB RAM*GT-630*DD-Cine V5.5*


    Client1-Yavdr
    0.4 -MSI Media LiveGehäuse mit Original board-2 GB Ram60 GB SSD -
    Nvidia Gt210 -DM140 Plugin-Pearldpf display-Harmony
    One
    Onkyo TX-NR906
    Sony-KDL Serie
    Teufel Concept E


    Client2
    Raspberry XBMC auf XBIAN Basis mit xvdr

    Einmal editiert, zuletzt von veni32 ()

  • Wird das kartenmörderische Verhalten des rpi durch Schreibzugriffe ausgelöst? Falls ja, leitet die wirklich um oder schaltet - wenn möglich - das syslog ab. Bei meinem Audio-rpi brauche ich das syslog nicht dauerhaft, also geht's in ein tmpfs. Falls nich die Schreibzugriffe Ursache für's Kartenmorden sind - was dann?

    LG
    Jochen


    Rpi4 headless mit MLD 5.4 als Server via satip-Plugin hinter einem Telestar Digibit Twin, ein Rpi3 als Streamdev-Client mit MLD 5.4

    Rpi3 auch hinter Telestar Digibit Twin und mit MLD 5.4

  • Ich weis jetzt nicht liegt es an schreib zyklen oder was weis ich,
    aber in openeelc und xbian foren ist problem bekannt und man spricht da von schreib zugriffe die karte in nirvana schicken.
    Wie das warheit enspricht weis ich nicht,
    aber ich hab das einfach geglaubt.
    Ich gehe da von einfach aus, das da leute sitzen die mehr ahnung als ich haben(und das ist nicht schwer :D )



    MfG

    Meine VDR Spielzeuge VDR1 -Yavdr 0.6*SilverStone SST-M02B-MXR-GIADA MG-C1037SL -Imon Lcd-Imon FB-
    Intel Celeron 1037U*4GB RAM*GT-630*DD-Cine V5.5*


    Client1-Yavdr
    0.4 -MSI Media LiveGehäuse mit Original board-2 GB Ram60 GB SSD -
    Nvidia Gt210 -DM140 Plugin-Pearldpf display-Harmony
    One
    Onkyo TX-NR906
    Sony-KDL Serie
    Teufel Concept E


    Client2
    Raspberry XBMC auf XBIAN Basis mit xvdr

  • speziellen Sandisks Ultra cards wird wohl auch nach gesagt, das sie getrimmt werden können

    Ich habe damals die Standard-Variante mit 16 GB gekauft, weil die in der Kompatibilitätsliste stand und lieferbar war. Die Ultra-Variante könnte sich wegen der langen Garantiedauer aber lohnen: http://www.sandisk.com/about-s…er-guides/warranty-table/

    yaVDR-Dokumentation (Ceterum censeo enchiridia esse lectitanda.)

  • Werde mich intrresiren wie der verhalten bei Rpi B+ ist mit microsd. Sind die auch so anfällig.


    die Micro-SDHC war diejenige, die es im Wandboard total entschärft hatte. Elektrisch sind sie auch gleich zu den SD Karten spezifiziert


    Zitat

    leitet die wirklich um oder schaltet - wenn möglich - das syslog ab.


    tmpfs oder ramlog können eine Menge abfedern, Journaling Daten werden trotzdem regelmäßig geschrieben. Abhängig von der Journaling Stufe des Dateisystems kann es da schon Unterschiede geben


    Zitat

    Falls nich die Schreibzugriffe Ursache für's Kartenmorden sind - was dann?


    ganz gefährlich sind Spannungsschwankungen und Stromausfälle, das mögen Flashspeicher generell nicht. Einfach den USB Stecker zum Reset nicht im richtigen Moment ziehen kann da schon tödlich sein. Da ist bsw. das nachrüsten des P6 sicherer.

  • Root ins Netzwerk geht nicht, weil der RPi ausschließlich von der SD-Karte bootet.


    Klar geht das. Das Raspberry Pi benötigt zwingend die Firmware und config.txt auf der SD-Karte, alles andere ist optional. Sogar der Kernel lässt sich mittels u-Boot über TFTP nachladen - hab ich getestet, ist mir aber doch zu umständlich. Zum Entwickeln nutz ich aber ein NFS-Root-FS, damit lässt sich auch leichter crosscompilieren.


    Zum Thema SD-Ausfälle kann ich leider nicht mitreden, ich nutze nun seit etwa einem Jahr im Schnitt drei RPIs und hatte noch nie Ausfälle. Allerdings übertakte ich auch nicht und die Logs werden übers Netzwerk weggeschrieben, Karten sind querbeet, von SanDisk uralt-Standard 2GB bis 16GB ultrairgendwas MicroSD.


    Gruss
    Thomas

  • Passt vielleicht nicht ganz: Auf meinem SheevaPlug (ARM v5) habe ich eine einfache 4 GB SD-Karte mit Debian seit 2011 (24/7) am laufen. Ich verwende Flashhybrid , welches die SD schreibgeschützt mountet und nur die Verzeichnisse wie z.B. /etc/ im RAM hält. Beim reboot und herunterfahren werden die Daten synchronisiert. Mit den Befehlen mountro und mountrw kann man das Dateisystem schreib bar machen, wenn mal Updates angesagt sind.


    Bis jetzt keine Probleme mit der SD-Karte. /var/mysql und solche Sachen habe ich ausgelagert auf ne kleine Laptopplatte...

  • Hab schon sehr viele verschiedene microSD-Karten auf ARM-Systemen benutzt, geht ueberwiegend sehr gut, insbesondere bei den billigen Karten-Serien (egal ob von Samsung, Transcend oder ganz billig) gibt es schon mal Fehler nach langem Gebrauch, deshalb nehme ich lieber die hochwertigeren Karten (UHS-Karten haben einfach bessere Controller). Insbesondere das Ueberbuegeln der ganzen Karte mit einem Image (ist ja im Arm-Umfeld nicht unueblich) moegen die Karten gar nicht.
    Wichtig ist, die Karten nicht nur neu zu formatieren, sondern wirklich zu loeschen. Alle SD-Karten beherrschen einen Erase-Befehl, nur leider reichen viele USB-Adapter ein Trim nicht als Erase durch. Wenn die Karten aber als MMC eingebunden sind, dann kann man die prima im u-boot loeschen (mmc erase) oder fuer den Laptop gibts z.B. ein Windows-Tool von sdcard.org.


    Gruss,
    S:oren

  • heute habe ich die RPI Karte mal über einen KL am Desktop gecheckt. Dort wurden Inodes und Blöcke repariert. Soweit so gut, auch wenn die Ursache noch unklar bleibt.
    Ich habe auch über rpi-update den mmc-driver gewechselt. Früher hatte ich in Anlehnung an diesen Thread hier --> http://www.raspberrypi.org/forums/viewtopic.php?f=63&t=19554&sid=298774260e35955f010ba103055b5b0a&start=25
    auch schon mal versucht, mit dieser Karte zu trimmen. Da gab es aber sofort eine Fehlermeldung (fstrim: /: FITRIM ioctl failed: Operation not supported)
    Jetzt habe ich es noch mal versucht, der RPI ist jetzt einige Zeit beschäftigt und zum Schluss gibt es folgende Meldung:


    Code
    root@pi:/etc/# fstrim -v /
    /: 137216000 bytes were trimmed


    Karte ist eine einfache ältere 4Gb Samsung

  • Hallo Thomas,

    Zitat

    Klar geht das. Das Raspberry Pi benötigt zwingend die Firmware und
    config.txt auf der SD-Karte, alles andere ist optional. Sogar der Kernel
    lässt sich mittels u-Boot über TFTP nachladen - hab ich getestet, ist
    mir aber doch zu umständlich.

    Gibt es eine Möglichkeit, den Server for dem NFS-Boot per wake on lan aufzuwecken?


    VG Uli

  • Gibt es eine Möglichkeit, den Server for dem NFS-Boot per wake on lan aufzuwecken?


    Vom Raspberry aus? Rein technisch gesehen könnte das die Firmware oder der Kernel übernehmen, aber das will niemand...


    NFS-Root ist eine feine Sache zum Entwickeln, aber im Produktiveinsatz sehe ich keinen Grund dazu. Um die SD-Karte zu schonen, würde ich wenn schon das Root-FS read-only mounten.


    Gruss
    Thomas

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!