Hi Habe jetzt schon meine dritte microSD Karte (Lexxar, Samung und Sandisk) in kurzer Zeit verloren. Ich hab z.B. heute grad unter Raspian gearbeitet, als plötzlich merkwürdige Fehlermeldungen kamen. Hab dann neu gestartet, nun bleibt der RasPi beim booten hängen. Die Karte formatieren kann ich nun auch nicht mehr, DIskpart schreibt zwar, dass die Karte erfolgreich gelöscht wurde, effektiv hat sich aber nix getan. Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD Karten übern Jordan gehen.
Kommt drauf an was du mit den Dingern machst und wieviele Daren auf die Karte geschrieben werden.
Chris schrieb: > nun bleibt der RasPi beim booten hängen Chris schrieb: > was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. - Du kannst die Zugriffsgeschwindigkeit von der SD ggf. runter tackten: In der /boot/config.txt (Muss man aber manuell rein schreiben) - Beim Neu-Installieren gleich /usr /home /tmp (...) sowie den SWAP auf nen schnellen externen Stick oder HDD (Partitionen) auslagern: Alles rüberkopieren bzw. Anlegen und dann im /etc/fstab mit defaults,nofail reinmounten. Wenn dann die Platte mal fehlt nimmt es den "Zustand" von der Karte. (Vom Neu-Install) - Dann kann mann noch irgendie im Filesystem die "File und Blocksize" genau auf den SD-Flash anpassen: man muss es entsprechend Formatieren und das Image dann manuell drauf extrahieren usw. (Weiß aber nichts genaues, hab ich noch nicht gemacht) - Readonly auf der Karte und viel Ramdisk für Cache /tmp (je nach dem was du machst) ist gut. Zu allem gibt es Anleitungen. Ich kann gar nicht so arg bestätigen dass die Karten flöten gehen, obwohl ich meistens hart ausschalte ohne die genannten Mods und ohne runterzufahren :-) Keine Ahnung was da bei dir loß ist. Man darf die bloß nicht im Handy Tablet oder sonnst wo Verschlüsseln (mit Karten-HW-Verschlüsselung) und dann einfach wo anders formatieren. Versuch vielleicht mal dieses SD-Assi-Tool und noch ein paar andere Cardreader.
:
Bearbeitet durch User
Hab eine einzige moderne kaputte 64GB SD, die irgendwann nach ~30 Minuten mit dd die zeros dann trotzdem noch bis zum Speicher-Ende annimmt, aber das ändert dann auch nichts: Die kann man nicht mehr formartieren. Da war aber nicht der Pi schuld sondern eben das mit dem Verschlüsseln. Vielleicht ist dein SD-Image das du (immer wieder) schreibst fehlerhaft? Und der Pi macht irgend ein SelfDistroy RussischRoulette? Versuch mal Image CRC-check oder einfach nochmal neu runterladen!
:
Bearbeitet durch User
kann aber auch sein, dass DU am Ende der writecycles bist
viele Karten erlauben nur begrenzt viele Schreibzyklen. (100.000
maximale.. üblicherweise crashen die aber schon ab 10-25k je nachdem
welcher sektor da beschreieben wurd)
wenn Du also 'viele' Daten schreibst ist es sinnvoller den handle
offenzuhalten solange das System läuft als es nach jeder Datei zu
schliessen
("karte für schnelles entfernen optinmieren" oder so heisst die
abzuschaltende Funktion häufig)
Wo das bei Raspian steckt kann ich Dir nciht sagen, sollte aber
dokumentiert sein.
Schreibt man zB logs (server/gamedata..what have you) ist das der
schnellste Tod einer SD Karte de man sich denken kann.. manche Karten
halten da nur Stunden durch.
das ist Zeug was eine echte Festplatte (besser scheibe als solid state)
braucht.
Mit etwas Glück kannst Du die SD Karte noch lesen (aus einem gebooteten
system heraus) vermutlich aber auch eher nciht.
Naja die RPi Foren sind voll davon welche karte mit wear levelling oder
ohne welche Einstellung et.pp.
IMHO booten von SD ist dufte, karte aber schreibgeschutzt und Userdaten
auf anderes Medium (ne 1.8" HDD zB aus nem alten iPod oder so... klein,
macht krach und hat nur 60GB oder son schmarrn aaaaaaber hält dafür
schreibzyklen bis der Arzt kommt)
'sid
Chris schrieb: > Hi > > Habe jetzt schon meine dritte microSD Karte (Lexxar, Samung und Sandisk) > in kurzer Zeit verloren. Ich hab z.B. heute grad unter Raspian > gearbeitet, als plötzlich merkwürdige Fehlermeldungen kamen. Hab dann > neu gestartet, nun bleibt der RasPi beim booten hängen. Die Karte > formatieren kann ich nun auch nicht mehr, DIskpart schreibt zwar, dass > die Karte erfolgreich gelöscht wurde, effektiv hat sich aber nix getan. > > Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. Was läuft denn auf dem RasPi? Nur Raspian im Original oder benutzt Du das Teil als WebCam mit 15 Bildern pro Sekunde und dann immer wieder überschreiben? Oder LOG-Orgie für jeden Systempups...?
Chris schrieb: > Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. Spannung am Raspberry unter Last messen. Gutes Netzteil einsetzen (5,2V; mind 2 bis 2,5A). Spannungseinbrüche haben durchaus Auswirkungen.
Chris schrieb: > Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. Hi Chris, das Problem kenn ich. Meine Raspbis fressen auch regelmäßig SD-Karten, 4-5 Stück waren das die letzten Jahre. Dein Fehlerbild deckt sich genau mit meinen Beobachtungen. Die Standard-Antwort ist immer: "Du musst was falsch machen, bei mir läuft alles ohne Probleme". Hab mittlerweile viele Hersteller und Preisklassen durch, das Netzteil ist auch kein Billigteil. Meine Lösung: 24/7-Anwendungen hab ich alle auf einen NUC migriert. Wenn man sich mal an dessen Leistung und das einfache Handling und Sichern von VMs unter Proxmox gewöhnt hat will man eh nichts anderes mehr. Ich hab noch zwei Raspis im Einsatz die aber nur bei Bedarf für wenige Stunden hoch- und runtergefahren werden.
Le X. schrieb: > Chris schrieb: >> Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD >> Karten übern Jordan gehen. > Dein Fehlerbild deckt sich genau mit meinen Beobachtungen. > Die Standard-Antwort ist immer: "Du musst was falsch machen, bei mir > läuft alles ohne Probleme". Ja, die Frage kam ja nicht von ungefähr: Das Speichermedium ist für Dauerbeschuss auf immer die gleichen Dateien (z.B. Zähler hoch oder runter) im gleichen PAGE-Bereich nicht geeignet. > Ich hab noch zwei Raspis im Einsatz die aber nur bei Bedarf für wenige > Stunden hoch- und runtergefahren werden. Meine Raspi Zero + CAM hängen das ganze Jahr am Nistkasten und schicken die Bilder auf ein NAS bzw. senden nur einen Stream - keine LOG-Datei-Orgien. Da säuft höchstens mal der Raspi ab, aber die Karte geht immer noch nach 2 Jahren.
Le X. schrieb: > Hi Chris, > > das Problem kenn ich. > Meine Raspbis fressen auch regelmäßig SD-Karten, 4-5 Stück waren das die > letzten Jahre. Bei mir läuft seit >1J 24/7 LibreELEC/Kodi, auf einer SanDisk Extreme Pro. Noch ist kein Ausfall zu beklagen --> TestX schrieb: > Kommt drauf an was du mit den Dingern machst und wieviele Daren auf die > Karte geschrieben werden.
Le X. schrieb: > Die Standard-Antwort ist immer: "Du musst was falsch machen, bei mir > läuft alles ohne Probleme". Die Standardantwort beim Raspi lautet, und das, seit dem es das Ding gibt: Die SD-Karten sind wegen ihrer begrenzten Schreibzykluszahl nicht für den Dauerbetrieb geeignet, und gehen daher alle früher oder später kaputt. YMMMV - Kartenqualität, Anwendung, logfiles, usw. Da die Dinger aber inzwischen über USB booten können, lassen sich diese Probleme einfach mit einer SSD lösen. Oliver
Uwe D. schrieb: > Meine Raspi Zero + CAM hängen das ganze Jahr am Nistkasten und schicken > die Bilder auf ein NAS bzw. senden nur einen Stream - keine > LOG-Datei-Orgien. Da säuft höchstens mal der Raspi ab, aber die Karte > geht immer noch nach 2 Jahren. Ja sowas in der Art habe ich seit zwei Jahren auch. Allerdings werden die Videos & Bilder bei mir auf der SD Karte gespeichert und nach dem Rotationsverfahren nach einigen Monaten automatisch wieder gelöscht. Daneben werden noch ein paar Umweltdaten im Minutentakt aufgezeichnet. Da ist noch nichts passiert, die Karte funktioniert nach wie vor einwandfrei. Es gibt halt einige Dinge zu beachten sind: - permanenten Speicher im systemd journald abschalten - eventuell rsyslogd verwenden und nur ganz selektiv Ereignisse in SD-Karten Partitionen loggen - Bei allen Server Programmen nur die unbedingt notwendigen logs aktivieren, der Zugrifss-Log des Webservers sind hier oft heiße Kandidaten - alle Partitionen mit noatime mounten - Unbedingt die Raspi Partition auf die volle SD-Karten Größe aufblasen, das hilft dem Wear-Leveling der SD-Karte - Eventuell ein anderes Dateisystem verwenden, z.B. Btrfs oder noch besser F2FS (Auf MMC/SD-Karten optimiert)
Keine Ahnung vom Raspberry, aber von SDcards unter "Dauerbeschuss". Anwendung ist ein Verkehrserfassungssystem mit µC der, falls keine Verbindung zum Server besteht, auf SDCard zwischenpuffern muss. Das haben die Karten paar Monate überlebt, dann waren sie kaputt. Nach Umstellung auf Industriequalität (die haben eine andere Topologie und kosten gerne das Doppelte) war Ruhe. Ich kann mich an keinen Ausfall danach erinnern. An den Herstellernamen kann ich mich nicht erinnern, fing glaub ich mit "a" an. **Örks**
evtl. swissbit? https://www.swissbit.com/en/products/nand-flash-products/sd-memory-cards/ bzw. https://www.swissbit.com/de/microsd-speicherkarten/ Stichwort für die Suche ist auch noch "Endurance". Hier https://www.raspberrypi.org/forums/viewtopic.php?t=182452 und https://www.raspberrypi.org/forums/viewtopic.php?f=91&t=288190&p=1744501&hilit=endurance&sid=3aff15cffc1537e547b451caea676d04#p1744501 weitere Tipps dazu.
:
Bearbeitet durch User
Chris schrieb: > Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. Ganz einfach: benutze kein System mehr, was nur SD-Karten als Massenspeicher benutzt. Es gibt genug Alternativen mit EMMC, die diese Probleme nicht haben. fchk
Thomas S. schrieb: > evtl. swissbit? Swissbit stand zur Diskussion, der lokale Vertreter dafür war hier, waren es aber nicht. Waren wohl zu teuer. :-/ Ist wohl auch egal, diese Endurance Typen (Danke für das Stichwort "Endurance") gibt es von mehreren, auch den üblichen Verdächtigen.
Oliver S. schrieb: > Le X. schrieb: >> Die Standard-Antwort ist immer: "Du musst was falsch machen, bei mir >> läuft alles ohne Probleme". > > Die Standardantwort beim Raspi lautet, und das, seit dem es das Ding > gibt: Die SD-Karten sind wegen ihrer begrenzten Schreibzykluszahl nicht > für den Dauerbetrieb geeignet, und gehen daher alle früher oder später > kaputt. > > YMMMV - Kartenqualität, Anwendung, logfiles, usw. Ne mein mind varied nicht, ich weiß ja auch an was es liegt. Im Endeffekt kommt aber raus dass der Raspi einfach für manche Usecases nicht oder nur schlecht geeignet ist. Ich kann zwar rumdoktoren und versuchen, die Probleme in den Griff zu bekommen, für mich habe ich aber die Entscheidung getroffen Systeme zu verwenden die "nativ" für den angedachten Usecase verwendbar sind. Der Rp4 wär übrigens relativ gut geeignet, kam aber (für mich) zu spät. Außerdem hat er immer noch andere Nachteile die ihn für mich unartraktiv machen. Dem TE wurden jedenfalls gute Ansätze gegeben um das Ganze in den Griff zu kriegen, vielleicht kriegt er ja seine Usecases damit umgesetzt.
:
Bearbeitet durch User
Chris schrieb: > neu gestartet, nun bleibt der RasPi beim booten hängen. Die Karte > formatieren kann ich nun auch nicht mehr, DIskpart schreibt zwar, dass > die Karte erfolgreich gelöscht wurde, effektiv hat sich aber nix getan. Schon mal mit dem "SD Memory Card Formatter" von sdcard.org probiert? sid schrieb: > viele Karten erlauben nur begrenzt viele Schreibzyklen. (100.000 > maximale.. üblicherweise crashen die aber schon ab 10-25k je nachdem > welcher sektor da beschreieben wurd) Streich da mal ne Null, 1k-2,5k kommt eher hin. Uwe D. schrieb: > Ja, die Frage kam ja nicht von ungefähr: Das Speichermedium ist für > Dauerbeschuss auf immer die gleichen Dateien (z.B. Zähler hoch oder > runter) im gleichen PAGE-Bereich nicht geeignet. Das ist jetzt aber "Festplatten-Denke". Wo ein Flashspeichermedium tatsächlich hinschreibt, hat überhaupt nix damit zu tun, in welche Datei Du schreibst. Oliver S. schrieb: > Die Standardantwort beim Raspi lautet, und das, seit dem es das Ding > gibt: Die SD-Karten sind wegen ihrer begrenzten Schreibzykluszahl nicht > für den Dauerbetrieb geeignet, und gehen daher alle früher oder später > kaputt. > > YMMMV - Kartenqualität, Anwendung, logfiles, usw. > > Da die Dinger aber inzwischen über USB booten können, lassen sich diese > Probleme einfach mit einer SSD lösen. Na, den Satz oben kannst Du doch ebenso auf SSDs anwenden. Andreas M. schrieb: > - Unbedingt die Raspi Partition auf die volle SD-Karten Größe aufblasen, > das hilft dem Wear-Leveling der SD-Karte ??? Eine SD-Karte weiß doch, bis auf evtl. eine Ausnahme (s.u.) gar nicht, was eine Partition ist. Und, wie ich oben schon mal schrieb: Wo Du meinst, in der von Dir gewählten logischen Struktur hinzuschreiben, hat nix damit zu tun, wohin der Controller die Daten physisch hin verlagert. > - Eventuell ein anderes Dateisystem verwenden, z.B. Btrfs oder noch > besser F2FS (Auf MMC/SD-Karten optimiert) Für SDXC und damit für Karten über 32GB ist explizit exFAT vorgesehen. So steht's in der zugehörigen Spec. Es ist jetzt nicht unvorstellbar, daß man die/den Karte/Controller darauf hin optimiert.
M.M.M schrieb: >> Da die Dinger aber inzwischen über USB booten können, lassen sich diese >> Probleme einfach mit einer SSD lösen. > > Na, den Satz oben kannst Du doch ebenso auf SSDs anwenden. Den Satz kann man auf alles vom Higgs-Teilchen bis zum Universum anwenden. Die Lebensdauer üblicher SSDs dürfte die des Raspis weit übersteigen (erst Recht, wenn die nicht nur 32MB hat), und das sollte bei jeder Anwendung locker ausreichen. Wenn nicht, sollte man ernsthaft über die grundsätzliche Hardwareauswahl oder aber das ganze Projekt nachdenken. Oliver
:
Bearbeitet durch User
Hm, meine Erfahrung ist ehr das es auch stark vom Hersteller und Art der Karte abhängt, betreibe Gentoo (also auch ständiges Compilieren) + Swap + Logs und ständiges schreiben in eine Datenbank. Mal ne kleine Auflistung: Samsung EVO 32GB (die Gelben) 2 Jahre (mittlerweile bei drei Karten) Samsung EVO Plus (die Roten) 1,5 Jahre Transcend Premium 32GB ~6 Monate Ansonsten ist es halt auch wie bei SSD um so größer die Karte um so länger hält sie, hab ne zeit lang 8/16GB benutzt die verschleißen logischerweise deutlich schneller.
Ich nehme deswegen keine Raspis mehr und bin auf OrangePi (One bzw Zero, gibt es auch in grösser) umgestiegen. Die killen keine SD-Karten.
M.M.M schrieb: > Streich da mal ne Null, 1k-2,5k kommt eher hin. bei nem einzelnen Sektor haste Rcht, aber ne Karte die nach dem tausendsten nutzen stirbt hab ich auch noch nicht gesehen.. auf sone Speicherkarte passen ja schonmal gerne 10k fotos wenn man nur 1000 machen könnte bevor die Karte die Beine streckt, wär das schon überraschend ;) 'sid
...-. schrieb: > Ich nehme deswegen keine Raspis mehr und bin auf OrangePi (One bzw Zero, > gibt es auch in grösser) umgestiegen. Die killen keine SD-Karten. Hier wird ein Müll von Beiträgen abgeladen, man glaubt es kaum. Die Krone ist natürlich der obige Beitrag, der so dämlich ist, dass er mich vor Zorn beben lässt.
1 | Falsch : Der Raspberry Pi 'grillt' SD-Karten. |
2 | Richtig : Viele hier sind zu doof, um mit dem Pi umzugehen. |
Ich setze seit 2012 Raspberrys in Stückzahlen ein ohne jemals auch nur eine einzige SC-Card 'gegrillt' zu haben. kwt.
Dieter schrieb: > Falsch : Der Raspberry Pi 'grillt' SD-Karten. Wer lesen kann, ist eindeutig im Vorteil, ich habe auch nicht geschrieben, dass der RPi Karten 'grillt' ... ;)
M.M.M schrieb: > Eine SD-Karte weiß doch, bis auf evtl. eine Ausnahme (s.u.) gar nicht, > was eine Partition ist. Und, wie ich oben schon mal schrieb: Wo Du > meinst, in der von Dir gewählten logischen Struktur hinzuschreiben, hat > nix damit zu tun, wohin der Controller die Daten physisch hin verlagert. Natürlich "weis die Karte das erstmal nicht"[*], aber wenn z.B. auf einer 16GByte Karte nur eine 2GByte Partition angelegt wird, also vom OS nur die ersten 2GB benutzt werden, dann kann/wird das OS die restlichen 14 GB auch nicht als unbenutzt (TRIM/ERASE Kommando) markieren. Je nach SD-Controller / Benutzungshistorie dieser SD Karte kann es dann sein, dass der SD-Controller die 14GB Speicher nicht als unbenutzt erkennt und sie damit auch nicht in das Wear-Leveling einbezieht. Wäre hier dann mal mindestens ein Faktor 7 in der Lebensdauer. Wenn man jedoch die volle Größe der SD Karte benutzt, dann kann beim Formatieren der Partition mittels TRIM zunächst mal der gesamte Speicher als unbenutzt markiert werden. Logischerweise darf man die Partition dann natürlich nicht komplett vollschreiben wenn man davon profitieren will. [*] Wenn man Zugriff auf die vollständig SD-Karten Spezifikation hat (Ich habe das), dann findet man darin ein eigenes Dokument welches Empfehlungen für Partionierung und Dateisysteme macht. Es ist explizites Anliegen dieses Dokuments, den SD-Kartencontrollern zu ermöglichen den Inhalt der SD-Karte zu verstehen und das Wear-Leveling daraufhin zu optimieren. Dieses Dokument existiert nicht erst seit SDXC. Das von mir oben erwähnte F2FS wurde auch im Hinblick auf dieses Dokument optimiert.
Dieter schrieb: > Richtig : Viele hier sind zu doof, um mit dem Pi umzugehen. > > Ich setze seit 2012 Raspberrys in Stückzahlen ein ohne jemals auch nur > eine einzige SC-Card 'gegrillt' zu haben. kwt. Wenn du jetzt für die vielen Unwissenden einfach noch dazu geschrieben hättest, was das Geheimnis der langen SD-Karten-Lebensdauer deiner Meinnung nach ist, wäre dein Beitrag ja glaubwürdig. So ist es einfach nur getrolle. Oliver
Oliver S. schrieb: > wenn du jetzt für die vielen Unwissenden einfach noch dazu geschrieben > hättest, was das Geheimnis der langen SD-Karten-Lebensdauer deiner > Meinnung nach ist Vielleicht verwendet er ihn als intelligente Türklingel und schreibt nur Updates auf die Karte.
Oliver S. schrieb: > Dieter schrieb: >> Richtig : Viele hier sind zu doof, um mit dem Pi umzugehen. >> >> Ich setze seit 2012 Raspberrys in Stückzahlen ein ohne jemals auch nur >> eine einzige SC-Card 'gegrillt' zu haben. kwt. > > Wenn du jetzt für die vielen Unwissenden einfach noch dazu geschrieben > hättest, was das Geheimnis der langen SD-Karten-Lebensdauer deiner > Meinnung nach ist, wäre dein Beitrag ja glaubwürdig. So ist es einfach > nur getrolle. > > Oliver Die Stichworte kamen doch schon, nur die Suchmaschine Deines Misstrauens anwerfen. Geht mit dem RasPi, mit dem iPad, dem PC, dem Handy - auch einem Orange Pi.... https://www.tuxlog.de/raspberrypi/2014/die-sd-karte-beim-raspberry-pi-schonen/
Chris schrieb: > Jedenfalls meine Frage ist, was ich tun kann, dass nicht noch mehr SD > Karten übern Jordan gehen. Solange Du hier keine weiteren Informationen lieferst und zu nichts äußerst, ist die Frage ganz einfach zu beantworten: NICHTS Gib einfach mal im Terminal ein "sudo fdisk -l", "swapon" und zeige den Aufbau der Partitionen. Anbei ein Beispiel:
1 | sudo fdisk -l |
2 | |
3 | Device Size Id Type |
4 | /dev/mmcblk0p1 256M c W95 FAT32 (LBA) |
5 | /dev/mmcblk0p2 48G 83 Linux |
6 | /dev/mmcblk0p3 8G 83 Linux |
7 | /dev/mmcblk0p4 2G 82 Linux swap / Solaris |
8 | |
9 | swapon |
10 | |
11 | NAME TYPE SIZE USED PRIO |
12 | /var/swap file 100M 0B -2 |
13 | /dev/mmcblk0p4 partition 2G 6.3M 5 |
Sandfrog schrieb: > Mal ne kleine Auflistung: Samsung EVO 32GB (die Gelben) 2 Jahre > (mittlerweile bei drei Karten) > Samsung EVO Plus (die Roten) 1,5 Jahre > Transcend Premium 32GB ~6 Monate Sind das die Zeiten bis die Karten ausgefallen sind, oder wie lange sie schon laufen ohne bisher ausgefallen zu sein? ...-. schrieb: > Ich nehme deswegen keine Raspis mehr und bin auf OrangePi (One bzw Zero, > gibt es auch in grösser) umgestiegen. Die killen keine SD-Karten. Interessant... gibt es dafür eine Erklärung? Ich kenne die Orange Pi jetzt nicht im Detail, aber meines Wissens sind das ja ebenfalls wie der Raspi ARM-Rechner die üblicherweise mit einem Linux betrieben werden. Interessant wäre daher, welches Detail dort anders ist...?
Andreas M. schrieb: > M.M.M schrieb: >> Eine SD-Karte weiß doch, bis auf evtl. eine Ausnahme (s.u.) gar nicht, >> was eine Partition ist. Und, wie ich oben schon mal schrieb: Wo Du >> meinst, in der von Dir gewählten logischen Struktur hinzuschreiben, hat >> nix damit zu tun, wohin der Controller die Daten physisch hin verlagert. > > Natürlich "weis die Karte das erstmal nicht"[*], aber wenn z.B. auf > einer 16GByte Karte nur eine 2GByte Partition angelegt wird, also vom OS > nur die ersten 2GB benutzt werden, dann kann/wird das OS die restlichen > 14 GB auch nicht als unbenutzt (TRIM/ERASE Kommando) markieren. Je nach > SD-Controller / Benutzungshistorie dieser SD Karte kann es dann sein, > dass der SD-Controller die 14GB Speicher nicht als unbenutzt erkennt und > sie damit auch nicht in das Wear-Leveling einbezieht. Wäre hier dann mal > mindestens ein Faktor 7 in der Lebensdauer. Ich denke mittlerweile auch, dass es wichtig ist einen möglichst großen Teil der Karte als unbenutzt markiert zu haben. Allerdings: kann mich an die Anfangszeit der SSDs erinnern, wo TRIM noch ein Thema war weil es noch etliche verbreitete OS gab die das nicht unterstützen. Da war die Empfehlung immer, einen (möglichst großen) Teil der SSD /un/partitioniert zu lassen. Von daher würde ich diese Empfehlung auf SD-Karten übertragen, falls es dort kein TRIM oder ähnliche Funktionalität gibt. Z.B. ist wohl über USB-Reader meist kein TRIM möglich, da das in dem verwendeten Standard-USB-Profil nicht enthalten ist. Ausnahme wären nur Reader die das über proprietäre Erweiterungen können plus entsprechende Treiber, aber bisher ist mir da keine existierende Lösung bekannt. Dabei sollte man natürlich sicherstellen, dass das Wear-Leveling der Karte diese vorher komplett als "unbenutzt" sieht. Dazu gibt's z.B. unter Linux ein Kommando -- ich hab es schon verwendet aber müsste nachschauen wie es hieß... Dieses funktioniert allerdings auch nicht über USB-Reader, aber z.B. interne Reader in Laptops sind üblicherweise nicht über USB angebunden, dort klappt das dann. > [*] Wenn man Zugriff auf die vollständig SD-Karten Spezifikation hat > (Ich habe das), dann findet man darin ein eigenes Dokument welches > Empfehlungen für Partionierung und Dateisysteme macht. Es ist explizites > Anliegen dieses Dokuments, den SD-Kartencontrollern zu ermöglichen den > Inhalt der SD-Karte zu verstehen und das Wear-Leveling daraufhin zu > optimieren. Dieses Dokument existiert nicht erst seit SDXC. > Das von mir oben erwähnte F2FS wurde auch im Hinblick auf dieses > Dokument optimiert. Gut zu wissen, danke! Von F2FS hatte ich zwar schon gehört aber es nie im Detail angeschaut, und wusste auch nicht dass es auch für SD speziell optimiert ist.
Mathias A. schrieb: > Sandfrog schrieb: >> Mal ne kleine Auflistung: Samsung EVO 32GB (die Gelben) 2 Jahre >> (mittlerweile bei drei Karten) >> Samsung EVO Plus (die Roten) 1,5 Jahre >> Transcend Premium 32GB ~6 Monate > > Sind das die Zeiten bis die Karten ausgefallen sind, oder wie lange sie > schon laufen ohne bisher ausgefallen zu sein? > Ist die Zeit die vergeht bis zum Ausfall, hab allerdings nix Optimiert wie gesagt Compiliere Gentoo auf dem SBC, Swap wird dabei auch reichlich genutzt und ccache und läuft 24/7. Bei den unteren beiden Karten hab ich nur eine jeweils getestet, da die Samsung EVO das gleiche kosten bleib ich auch dabei. > Interessant... gibt es dafür eine Erklärung? > Ich kenne die Orange Pi jetzt nicht im Detail, aber meines Wissens sind > das ja ebenfalls wie der Raspi ARM-Rechner die üblicherweise mit einem > Linux betrieben werden. Interessant wäre daher, welches Detail dort > anders ist...? Würde ehr drauf tippen das vielleicht die Spannungsversorgung das Problem ist z.b. schlechtes oder zu schwaches Netzteil, es könnte auch die art der Benutzung sein z.b. ständiges neu aufspielen von Images ..., wobei ich auch nicht bestätigen kann das der OPI bei mir weniger Karten frisst als der RPI. Ist bei mir recht gleich hab nen RPI2 und nen OPI-PC beide mit dem gleichen drauf hab mir irgend wann mal den OPI wegen dem Preis als Redundanz hingestellt, bis auf Kernel/Bootloader und beim OPI ext3/RPI=ext4).
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.