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.
Chris schrieb:> nun bleibt der RasPi beim booten hängenChris 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.
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!
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**
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.
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
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.
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:
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).
