Hi, Habe gehört, dass SD-Karten bei Raspberry Pi's sehr anfällig auf defekte sind, da der Raspberry sehr oft auf die SD-Karte schreibt und diese SD-Karten ja nicht für häufige Schreibzyklen ausgelegt sind. Gibt es einen ungefähren Anhaltspunkt, wie hoch die Lebensdauer einer handelsüblichen, preiswerten Class10 SD-Karte im dauerbetrieb ungefähr ist? Wie sieht es aus, wenn ich eine MLC oder SLC SD-Karte nehmen. Hat jemand speziell erfahrungen mit folgender gemacht?: https://ch.rs-online.com/web/p/micro-sd-karten/2405456 Habe gehört, dass die möglichkeit besteht, den einen Teil des Raspberry Betriebssystem in dem RAM zu laden, damit dieser nicht die SD-Karte belastet. Was ist an dieser These dran und falls das Sinnvoll wäre, wie stelle ich das an? Und was genau bewirkt das deaktivieren des "Overlay file system"? Welche Einschränkungen habe ich damit? Ich möchte ein Datenlogger für meine SD-Karte bauen und vielleicht im 30min- oder 1h-Takt die Daten auf der SD-Karte speichern. Mir ist daher wichtig, alle anderen Faktoren für einen defekt der SD-Karte zu minimieren. Danke
Manuel N. schrieb: > da der Raspberry sehr oft auf die SD-Karte schreibt Das hängt davon ab, was da für 'ne Software drauf läuft. Von sich aus tut er das nicht. Du könntest eine zweite SD-Karte für Deinen Datenlogger verwenden und die mit einem USB-SD-Kartenleser am Pi beschreiben. So bleibt die Karte für das Betriebssystem des Pi von Deinen Datenloggereien unberührt.
Manuel N. schrieb: > Gibt es einen ungefähren Anhaltspunkt, wie hoch die Lebensdauer einer > handelsüblichen, preiswerten Class10 SD-Karte im dauerbetrieb ungefähr ist? Kommt drauf an. Richtig billige Consumerware geht beim Dauerschreibversuch nach 3-4 Tagen kaputt. Gute Industriekarten halten mehrere Monate durch. Derzeit laufen hier 4 Stück Kioxia Exceria LMEX1L032GG2 32GB seit Mitte März und stellen sich damit recht gut auf. Mein Tipp aus dem inzwischen 8 Jahre dauernden Dauertest ist aber: "Xmore" von Glyn. Siehe das da https://www.mikrocontroller.net/search?query=xmore&sort_by_date=1 Und dort findest du ein paar totgetestete Exemplare: Beitrag "Re: Eure Erfahrungen mit SD-Karten" EDIT: Samsung-Karten stellen sich auch nicht ganz schlecht an...
:
Bearbeitet durch Moderator
Manuel N. schrieb: > Hi, > Habe gehört, dass SD-Karten bei Raspberry Pi's sehr anfällig auf defekte > sind, da der Raspberry sehr oft auf die SD-Karte schreibt und diese > SD-Karten ja nicht für häufige Schreibzyklen ausgelegt sind. Das ist alles relativ. Eines der wesentliche Probleme ist eher ein Stromausfall im Normalbetrieb. Dabei kann die SD-Karte beschädigt werden, zumindest auf logischer Ebene, weil Daten unvollständig geschrieben werden. > Habe gehört, dass die möglichkeit besteht, den einen Teil des Raspberry > Betriebssystem in dem RAM zu laden, Das passiert sowieso. Lesezugriffe sind kein Problem, sondern Schreibzugriffe. Die kann und sollte man vermeiden, indem man den SWAP-Bereich im Linuxkernel von der SD-Karte in den RAM verlagert. Wie das im Detail funktioniert, weiß ich nicht, findet man aber. > Ich möchte ein Datenlogger für meine SD-Karte bauen und vielleicht im > 30min- oder 1h-Takt die Daten auf der SD-Karte speichern. Das ist unkritisch. Wenn man dann nach dem Zugriff einen "Flush" der Zwischenpuffer ausführt, werden alle Daten komplett auf die SD-Karte geschrieben und ein möglicher Ausfall der Versorgungsspannung führt nicht zur Datenverlust oder Zerstörung.
Lothar M. schrieb: > Manuel N. schrieb: >> Gibt es einen ungefähren Anhaltspunkt, wie hoch die Lebensdauer einer >> handelsüblichen, preiswerten Class10 SD-Karte im dauerbetrieb ungefähr ist? > Kommt drauf an. Richtig billige Consumerware geht beim > Dauerschreibversuch nach 3-4 Tagen kaputt. In deinem Aufbau mit deinen, speziellen Zugriffsmustern. Allgemein gilt das eher nicht.
Manuel N. schrieb: > einen ungefähren Anhaltspunkt, wie hoch die Lebensdauer einer > handelsüblichen, preiswerten Class10 SD-Karte im dauerbetrieb ungefähr > ist? Das hängt ganz von den Fähigkeiten des Benutzers/Administrator ab. Bei mir läuft eine auf einem Raspi Zero aufsetzende Wildkamera seit gut vier Jahren, Videoaufzeichnung bei Bewegung, max 4 Videos á 15 Minuten / Stunde. Dazu jede Minute Aufzeichnung Temperatur, Akkuspannung, Helligkeit, LTE Volumen. Andere bekommen die Karte wohl in wenigen Monaten klein. Das man nur anständige SD-Karten von Namenhaften Herstellern einsetzt erklärt sich von selbst. Wichtig ist, dass man vor allem die ganzen Logs auf nötigste reduziert. D.h. dem jounald das persistente Speicher der Logs untersagen und evtl. einen vernünftigen Log-Dienst wie rsyslogd nutzen bei dem man das granularer konfigurieren kann.
Es macht imho Sinn, eine SD-Karte mit großer Kapazität zu nehmen und nur einen kleinen Teil davon zu benutzen bzw zu belegen. Wegen dem Wear-Leveling-Verfahren werden die Schreibzugriffe auf die noch freien Speicherplätze verteilt, sodass jede Speicherzelle weniger bzw seltener seltener von Schreibzugriffen belastet wird als wenn nur wenig freier Speicherplatz auf der Karte ist. Dadurch müsste de SD länger 'halten' - wolfi0 -
Falk B. schrieb: > In deinem Aufbau mit deinen, speziellen Zugriffsmustern. Allgemein gilt > das eher nicht. Allgemein waren halt bei gleicher Software und gleicher Maschinenkonstellation die billigen Consumer-Karten nach 5 Wochen kaputt und die anderen nach einigen Jahren nicht signifikant. Und ich spreche dabei von einigen tausend Karten ind einigen tausend Maschinen. Aber wie gesagt: da kann sich für kleines Geld jeder selber so einen Teststand aufbauen (mein Tipp: den Powerfail mit in den Test einbauen, der macht so macher Karte unerwartete Probleme) und eigene Erkenntnisse sammeln. Ich stelle ihm dann auch ein paar Xmore-Karten zur Verfügung und bin wirklich froh, wenn er andere findet, die genauso gut sind. Denn ich suche im Grunde nur nach einer Second-Source... Falk B. schrieb: > Wenn man dann nach dem Zugriff einen "Flush" der Zwischenpuffer > ausführt, werden alle Daten komplett auf die SD-Karte geschrieben und > ein möglicher Ausfall der Versorgungsspannung führt nicht zur > Datenverlust oder Zerstörung. Die Karte darf nach letzten Zugriff (also dem Flush-Ende) noch über 500ms aktiv sein. Und das sind die Karten teilweise auch. Man muss nur mal die Stromaufnahme nach dem Schreiben messen... Nicht umsonst gibt es die üblichen 1-Sekunden-USV basierend auf SuperCaps. Wolfgang S. schrieb: > Wegen dem Wear-Leveling-Verfahren werden die Schreibzugriffe auf die > noch freien Speicherplätze verteilt So die Vermutung. Aber lies einfach mal die Links, die sich mit der obigen Suche finden. Einer der sich mit der Firmware beschäftig, ist z.B. der dort: Beitrag "Re: zuverlässige SD-Karte für Raspberry Pi" Und wenn du dann noch statische Daten auf der Karte hast, dann wird es ganz lustig, wenn die sich auf einmal "selbständig" ändern, obwohl sie nur gelesen werden: Beitrag "Re: Eure Erfahrungen mit SD-Karten"
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Denn ich suche im Grunde nur nach einer Second-Source... Swissbit? Ich hatte mit den Karten vor 15Jahren zu tun. Soweit ich mich erinnern konnte waren das die Besten in unserem Test damals Wir gingen aber mit dem Loggen auf SD-Karte aber dann nie in Serie... 73
Hans W. schrieb: > Swissbit? Ich hatte die Swissbit 4GB S45u durabit SFS4096N2BM1T0-E-GE2A1-STD im Test. Und die zeigen ein sehr ambivalentes Bild: 1 Karte war nach 1 Monat kaputt, die 3 anderen haben 2 bzw. 3 Monate durchgehalten. Ganz schlecht vertragen haben sie, dass sie für 1 Jahr spannungsfrei gelagert wurden. Aber das war 2017, ich muss da mal eine neuere Serie testen...
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Mein Tipp aus dem inzwischen 8 Jahre dauernden Dauertest ist aber: > "Xmore" von Glyn. Lothar M. schrieb: > EDIT: Samsung-Karten stellen sich auch nicht ganz schlecht an... Hast Du da ungefähre Vergleichswerte von Totschreib-Tests und konkrete getestete Modelle parat? Von den aktuellen Samsung-Karten dürfte wohl die "Pro Endurance", die für Videoaufzeichnung beworben wird, am ehesten dafür geeignet sein, aber im Gegensatz zu SSDs gibt's natürlich keine garantierten TBW.
> 1 Karte war nach 1 > Monat kaputt, die 3 anderen haben 2 bzw. 3 Monate durchgehalten. Man sollte bei manchen Anwendungen ganz auf SD-Karten verzichten. Ich finde es nicht akzeptabel einem Kunden etwas "anzudrehen" wo das eigentliche Betriebsmedium mit einer Wahrscheinlichkeit groesser als Null bei seiner Nutzung versagt.
Hmmm schrieb: > Von den aktuellen Samsung-Karten dürfte wohl die "Pro Endurance", die > für Videoaufzeichnung beworben wird, am ehesten dafür geeignet sein, Das Hauptproblem ist hier, dass das Wearleveling beim Streamen von großen Dateien anders gehandhabt wird als das Schreiben von vielen kleinen Informationsfragmenten und kleinen Dateien wie es bei Logfiles der Fall ist (ständig Datei öffnen, Daten schreiben, Datei schließen). Und deshalb kann man nicht von "schnell und teuer" auf "geeignet für viele kleine Dateien" extrapolieren. Da musste ich doch grade nachschauen. Und finde Bedenkliches: ich hatte im ab Mitte Juni 2021 die Samsung EVOPlus 32GB MB-MC32G im Test. Und was sag ich: wwider Erwarten ist die erste der 4 Karten schon nach 2 Monaten auffällig geworden (eine read only Datei hatte sich verändert) und 2 Wochen später waren alle kaputt. Ich muss also meine Empfehlung etwas revidieren :-/ Beim exakt selben Test waren 2016 die Samsung EVO 8G MB-MP08D mit einer Lebensdauer von 5 Monaten deutlich robuster... Cartman schrieb: > Ich finde es nicht akzeptabel einem Kunden etwas "anzudrehen" > wo das eigentliche Betriebsmedium mit einer Wahrscheinlichkeit > groesser als Null bei seiner Nutzung versagt. Also hart verdrahtete Software? Und dann zum Handyupdate per EPROM-Tausch das Ding zum Hersteller schicken?
:
Bearbeitet durch Moderator
Lothar M. schrieb: > Ich muss also meine Empfehlung etwas > revidieren :-/ Danke, dann notiere ich mir mal die Xmore. Normalerweise nutze ich dort, wo viel geschrieben wird, Systeme mit "echten" SSDs, aber bei der Anforderung "möglichst klein" kommt man ja schwer um SD-Cards herum. Lothar M. schrieb: > Cartman schrieb: >> Ich finde es nicht akzeptabel einem Kunden etwas "anzudrehen" >> wo das eigentliche Betriebsmedium mit einer Wahrscheinlichkeit >> groesser als Null bei seiner Nutzung versagt. > Also hart verdrahtete Software? Er meinte wohl eher getrenntes Flash, damit das Gerät auch bei defekter SD-Card bootfähig bleibt und sie idealerweise kundenseitig getauscht werden kann. Eine Ausfallwahrscheinlichkeit von 0 ist allerdings ein utopischer Wunsch.
Hmmm schrieb: > Normalerweise nutze ich dort, wo viel geschrieben wird, Systeme mit > "echten" SSDs, aber bei der Anforderung "möglichst klein" kommt man ja > schwer um SD-Cards herum. Platz für eine 2,5"-SSD mit USB-Adapter sollte doch immer da sein. Oliver
Oliver S. schrieb: > Hmmm schrieb: >> Normalerweise nutze ich dort, wo viel geschrieben wird, Systeme mit >> "echten" SSDs, aber bei der Anforderung "möglichst klein" kommt man ja >> schwer um SD-Cards herum. > > Platz für eine 2,5"-SSD mit USB-Adapter sollte doch immer da sein. Das war jetzt nicht auf den RPi bezogen, sondern auf Embedded Devices allgemein. Eine MicroSD bekommst Du mit minimalem Platzbedarf in ein System integriert und per SPI an jeden Controller gehängt, bei einer SSD läuft es auf etwas Grösseres mit Embedded Linux o.dgl. hinaus.
Je nach Daten und Standort würde ich die Daten einfach direkt an einen Webservice übermitteln. Gibt da einige mit REST API, dann hat man die Daten auch direkt abrufbar und ggf. direkt aufbereitet. So musst die Daten ja sonst irgendwie vom Pi in deine Anwendung bekommen... SD Karte kannst bei einem Schreibzugriff die Stunde wenn es nicht all zu viel ist jedoch bedenkenlos machen, ich persönlich hatte damit bei Sandisk Extreme und auch den Samsung SD Karten keinerlei Probleme.
Hmmm schrieb: > Er meinte wohl eher getrenntes Flash, damit das Gerät auch bei defekter > SD-Card bootfähig bleibt und sie idealerweise kundenseitig getauscht > werden kann. Dafür setze ich 2 SDs ein: eine wird nur bei einem Kernelupdate beschrieben, und auf der anderen finden sich die Anwendersoftware und die Daten. Und ein anderer Dauertest zeigt, dass auch nach über 3 Millionen Powerfails diese Read-Only-System-SD nicht ausfällt, auch wenn sie aus der billigsten Consumerecke kommt.
:
Bearbeitet durch Moderator
Beitrag #7103168 wurde vom Autor gelöscht.
Angehängte Dateien:
-
read_only.png
12 KB
Für einen Fingernagelgroßen USB-Stick ist kein Platz? Das System ReadOnly auf die SD-Card. geschrieben wird auf den Stick. Wenn man einen SLC-Stick hat (teuer) kann man auch auf diesen das System installieren und booten. Eigentlich sollte das mit dem neuesten (Firmware-)Update bei allen Raspis klappen (zumindestens weiß ich es von Version 3 und 4). Als "Kartenkiller" war hauptsächlich die erste Baureihe berüchtigt, da die SD-Card beim "rumwerkeln" den Kontakt verlieren konnte und es dann zu Fehlern kam...mit dem Ergebniss, daß die SD-Karte defekt war. zum einlesen: https://learn.adafruit.com/assets/108775 Mr. Floppy
> Eine Ausfallwahrscheinlichkeit von 0 ist allerdings ein utopischer > Wunsch. Die mittlerweile 11 Jahre alte 16 GB SD-Karte in meinem "alten" Androiden funktioniert nach wie vor. Gemeint ist die Ausfahllwahrscheinlichkeit ueber den Zeitraum der aktiven Nutzung. Und ein Geraet das bereits nach wenigen Monaten versagt, hat einen Sachmangel im Design. Ein solches Geraet wuerde ich beim Verkaeufer/Hersteller reklamieren. Wenn SD-Karten durch die Anwendung beschrieben werden, muss man dafuer sorgen, dass nur in groesseren Bloecken geschrieben wird. Dazu muss das Design dann u.U. auch in der Lage sein bzw. gebracht werden. Ein kleiner 8 Bitter mit 1 k RAM zaehlt dazu augenscheinlich nicht. Es hilft auch nicht, bestimmte SD-Karten(-Typen) dem Benutzer zu empfehlen. Auf die Qualitaet dieser Karten hat der Geraetedesigner ja gar keinen Einfluss. Der RPi hat nun gleich mehrere dieser Sachmaengel im Design. Er schreibt auf die SD-Karte ein neues Filesystem, dass nicht fuer die schreibende Nutzung von SD-Karten vorgesehen war (und ist). Auch die Einstellungen des Betriebssystems werden nicht genutzt um die Situation zu verbessern. Aber er ist ja auch nur fuer Schueler und Bastler gedacht. Vielleicht sollte der Verkaeufer zur Anbringung eines Warnhinweises verpflichtet werden.
Cartman schrieb: > Der RPi hat nun gleich mehrere dieser Sachmaengel im Design. Was ja nun seit Anbeginn der Zeitrechnung bekannt ist, und u.a. auch zur Ausgangsfrage dieses Threads geführt hat. Aber schön, das da nochmals drüber gesprochen wurde. Oliver
> Aber schön, das da nochmals drüber gesprochen wurde.
Ich haette noch ergaenzen koennen, das die "Foundation" auch bei
den verwendeten Komponenten nur das allierbilligste vom
allierbilligen verbaut hat, und der ausgewaehlte SD-Karten-"Halter"
die Karten schon mechanisch zerbroeselt hat.
Ich habe bei meinem dann ein duennes Alublech drueber geklebt...
Viel hat schon gebracht, das Loggen abzuschalten. Auch beim Rest viel in ein Tempfs ins Ram schreiben. SD-Schreibzugriffe vermeiden. So hat mein OS schon ein paar Jahre überlebt. Bei neueren Raspi kann man auch von USB-SSD Booten. Die SSDs sind wesentlich stabiler.
Falk B. schrieb: > Schreibzugriffe […] kann und sollte man vermeiden, indem man den > SWAP-Bereich im Linuxkernel von der SD-Karte in den RAM verlagert. Naja … SWAP ist als Erweiterung / zur Auslagerung des RAM gedacht, wenn Letzteres nicht ausreicht. RAM über SWAP im RAM ins RAM auszulagern, ist nicht so ganz sinnvoll ;) Was aber geht, zumindest bei den Modellen mit etwas mehr RAM: man kann das gesamte System so ins RAM legen, dass auch die Schreibzugriffe fürs Log und für die Dateisystem-Metadaten nicht auf der Karte landen. Ansonsten habe ich in meinen Pi verhältnismäßig billige SD-Karten von SanDisk, drauf steht „Extreme“ – die machen sich überraschend gut, was die Haltbarkeit und auch die Geschwindigkeit angeht.
Manuel N. schrieb: > Habe gehört, dass die möglichkeit besteht, den einen Teil des Raspberry > Betriebssystem in dem RAM zu laden, damit dieser nicht die SD-Karte > belastet. Was ist an dieser These dran Gar nichts, denn das Betriebssystem wird bereits Standardmäßig ins RAM geladen und von dort aus ausgeführt. Du meinst vermutlich eher, dass man sich eine RAM-Disk anlegt und häufig veränderte Dateien dort ablegt. Kann man machen, aber bei Stromausfall ist dann alles weg. Solange du kein konkretes Problem zum analysieren hast, lass besser die Finger davon. Manuel N. schrieb: > Ich möchte ein Datenlogger für meine SD-Karte bauen und vielleicht im > 30min- oder 1h-Takt die Daten auf der SD-Karte speichern. Mir ist daher > wichtig, alle anderen Faktoren für einen defekt der SD-Karte zu > minimieren. Ich hatte einen Datenlogger 3 Jahre lang laufen lassen, der alle 10 Sekunden ungefähr 15 Zeilen in eine Log-Datei schreibt. Dabei traten keine Probleme auf.
Falk B. schrieb: > indem man den SWAP-Bereich im Linuxkernel von der > SD-Karte in den RAM verlagert Dann kann man ihn auch gleich deaktivieren und von entsprechend mehr freiem RAM profitieren. Swap Speicher ist ganz nett, wenn man ein Java Programm startet, das für sich alleine rücksichtslos 2 Gigabyte RAM reservieren will und davon nur einen Bruchteil benötigt. Insofern: Erst mal schauen, wie viel überhaupt auf den Swap zugegriffen wird. Normalerweise nämlich fast gar nicht. Wenn doch, merkt man das sehr deutlich an der System-Performance. Ich habe meine Karte mit vorinstalliertem Betriebssystem von der Raspi Foundation gekauft. Das war etwas teurer, aber so konnte ich sicher sein, dass die Karte für das System gut geeignet ist. Sie hat mich nicht enttäuscht: 3 Jahre Dauerbetrieb mit einem Datenlogger, insgesamt ist sie schon etwa 6 Jahre alt und funktioniert immer noch.
Stefan ⛄ F. schrieb: > Insofern: Erst mal schauen, wie viel überhaupt auf den Swap zugegriffen > wird. Normalerweise nämlich fast gar nicht. Wenn doch, merkt man das > sehr deutlich an der System-Performance. Man kann über /proc/sys/vm/swappiness einstellen, wie aggressiv der Kernel auszulagern versucht. Die Dokumentation findet sich unter /usr/src/linux/linux-source-5.4.0/Documentation/admin-guide/sysctl/vm.rs t wenn man die Kernelsourcen installiert hat.
Stefan ⛄ F. schrieb: > Swap Speicher ist ganz nett, wenn man ein Java Programm startet, das für > sich alleine rücksichtslos 2 Gigabyte RAM reservieren will und davon nur > einen Bruchteil benötigt. Selbst das kann ohne Swap funktionieren. Der kernel genehmigt die 2GB erstmal, auch wenn es die physikalisch garnicht gibt. Erst, wenn das Programm den Speicher wirklich braucht, gibt es ein Unglück. > Insofern: Erst mal schauen, wie viel überhaupt auf den Swap zugegriffen > wird. Normalerweise nämlich fast gar nicht. Und schon garnicht, wenn da nur ein Datenlogger läuft. Zum Verlgeich: meine Desktop-PCs hatten noch nie mehr als 4GB RAM, swap ist komplett abgeschaltet, /tmp ist ein tmpfs und manchmal benutze ich firefox, chromium und palemoon gleichzeitig -- swap ist total überbewertet.
Neuere RPis können von SSD booten über USB. Trotzdem würde ich Logging und Swapping soweit es geht abschalten.
Hmmm schrieb: > SSDs Hmmm schrieb: > SSDs Oliver S. schrieb: > SSD PittyJ schrieb: > SSD Oliver S. schrieb: > SSD Eigentlich ist dem nichts mehr hinzuzufügen. Der TO ist allerdings erstmal in eine hier empfohlene Sackgasse abgebogen: Beitrag "Raspberry Pi, Daten über Webserver downloaden" Das wird aber nur von kurzer Dauer sein. Oliver
Ich habe in der Firma etwas über 30 RasPis als Info Displays laufen. Die ersten(noch RasPi 2, dann 3) laufen jetzt 6 Jahre 24/7. Es läuft ein unmodifiziertes Raspbian, also nix ReadOnly. Ich verwende grundsätzlich Samsung EVO+ 32GB(kann sein, daß in den allerersten noch was anderes drin ist). Es ist bis jetzt noch keine einzige kaputt gegangen. Uwe
:
Bearbeitet durch User
Manuel N. schrieb: > Gibt es > einen ungefähren Anhaltspunkt, wie hoch die Lebensdauer einer > handelsüblichen, preiswerten Class10 SD-Karte im dauerbetrieb ungefähr > ist? Schau mal in diesen Beitrag: Beitrag "zuverlässige SD-Karte für Raspberry Pi" Tipps von dort (Auswahl): -"Boote von SD und pack das gesamte root-FS auf eine USB-Disk!" -"Es gibt USB-Adapter für M.2 SSDs" -"Eine SATA-SSD via üblicher SATA-USB-Bridge tut's aber auch." In unseren Raspies (3B+) laufen folgende 32GB MicroSD Speicherkarten gut (Preis ca. 6 Euro): ---------------------------------------- Kingston CANVAS Select Plus SDCS2/32GB 31663-C04.A00LF ----------------------------------------
Bauform B. schrieb: > Selbst das kann ohne Swap funktionieren. Der kernel genehmigt die 2GB > erstmal, auch wenn es die physikalisch garnicht gibt OK, gut zu wissen. Das war nicht immer so, soweit ich mich erinnere. Vielleicht verwechsele ich das auch mit Windows.
Stefan ⛄ F. schrieb: > Bauform B. schrieb: >> Selbst das kann ohne Swap funktionieren. Der kernel genehmigt die 2GB >> erstmal, auch wenn es die physikalisch garnicht gibt > > OK, gut zu wissen. Das war nicht immer so, soweit ich mich erinnere. > Vielleicht verwechsele ich das auch mit Windows. Und wenn das Programm beginnt den Speicher zu nutzen, dann gibt es zwei Möglichkeiten: Wenn man swapspace hat, dann läuft das Programm weiter. Wenn man keinen swapspace hat, dann kommt der OOM-Killer. Kommt immer drauf an was einem wichtig ist. Prinzipien oder Funktionalität.
Norbert schrieb: > Wenn man swapspace hat, dann läuft das Programm weiter. Daumenregel: swap doppelt so groß wie das RAM, und dann? > Kommt immer drauf an was einem wichtig ist. > Prinzipien oder Funktionalität. langlebige SD-Karten oder beliebig große Speicherfresser.
:
Bearbeitet durch User
Bauform B. schrieb: > Norbert schrieb: >> Wenn man swapspace hat, dann läuft das Programm weiter. > > Daumenregel: swap doppelt so groß wie das RAM, und dann? Man konfiguriert sein System nicht nach Daumenregel sondern nach Bedarf. Zudem sind Daumenregeln aus dem letzten Jahrtausend nicht mehr unbedingt zielführend. >> Kommt immer drauf an was einem wichtig ist. >> Prinzipien oder Funktionalität. > > langlebige SD-Karten oder beliebig große Speicherfresser. Wenn man Speicherfresser nutzen will, dann muss man für Speicher sorgen. Sonst kann man's auch gleich sein lassen. Wenn man den Speicher jedoch nicht braucht, dann schadet der swapspace eben auch nicht. ›swapiness‹ ist ja bereits erwähnt worden.
Und was bringt einem das Overlay file system?...ist ja in meinem aktuellen Raspbian standardmässig mit drin. Oder ist das genau das, was in den obigen Beiträgen so umschrieben erklärt wurde? Hat ja auch mit den Schreibzugriffen auf die SD-Karte zu tun. Bin nicht extrem affin mit dem Raspberry, weswegen ich eine verhältnismässig unkomplizierte methode bevorzuge.
Es gibt inwischen M2-SSD-Adapter für den Raspi. Für ein Museums-Projekt (Touchscreen, Beamer u.a. auf Raspi) musste ich vorher aller 2 ... 3 Monate die SSDs neu schreiben und nach spätestens 2 Jahren austauschen. Seit dem Einsatz der SSD ist das vorbei.
Frank E. schrieb: > Es gibt inwischen M2-SSD-Adapter für den Raspi. Mir ist eine SATA SSD verreckt, eine Intel in einem M2 Hat eines RPis. Innerhalb von 1-2 Jahren bei sehr schwacher Nutzung. In etlichen RPis hat es bisher nur eine uSD erwischt, Altersschwäche. Und eine lang genutzte CompactFlash im Hat. Sterben tun sie alle.
:
Bearbeitet durch User
Ich hab gute Erfahrungen mit Samsung EVO 16/32GB (die Gelben) karten gemacht im PI4 b.z.w. vorher OPI die halten bei mir um im durchschnitt um 2 Jahre in einem unoptimierten Gentoo System inkl. emerge, den normalen logs und swap(mit dem PI4 kein Swap mehr sondern ZRAM zum Compilieren brauch ich hin und wieder leider Swap(mysql z.b. compiliert nicht ohne swap)) , logs in Mysql ... die sind schon Recht Robust. Momentan hab ich ne Rote EVO Plus drinnen die aber auch schon seit ca. einem Jahr Schlechte Erfahrungen mit dem gleichen System hab ich bei Intenso, Transcend, Verbatim gemacht die waren oft nach wenigen Monaten Defekt.
:
Bearbeitet durch User
Manuel N. schrieb: > Und was bringt einem das Overlay file system?...ist ja in meinem > aktuellen Raspbian standardmässig mit drin. Oder ist das genau das, was > in den obigen Beiträgen so umschrieben erklärt wurde? Ja und nein. Technisch und von der Bedienung her ist es etwas ganz anderes. Die Wirkung ist allerdings die gleiche - die SD-Karte wird geschont. Es ist eine rund-um-sorglos alles-oder-nichts Lösung. Du kannst es nur einschalten oder eben nicht. Und es verhindert komplett alle Schreibzugriffe auf die Karte (oder eben keinen). Die obigen Vorschläge sind technisch viel einfacher, aber du kannst (musst) sie individuell konfigurieren. Weil das Overlay alle Daten im RAM speichert, muss der Datenlogger seine Daten irgendwo anders speichern. Oder sie gehen bei einem Stromausfall verloren. Ein praktische Lösung wurde schon mehrfach vorgeschlagen: ein USB-Stick. > Bin nicht extrem affin mit dem Raspberry, weswegen ich eine > verhältnismässig unkomplizierte methode bevorzuge. Dann schalte das Overlay ein vergiss alles andere. Nachteil: bei einem Stromausfall gehen Daten verloren. Aber: Wahrscheinlich will man die Daten ja regelmäßig auf einem PC o.ä. anschauen und archivieren. Verrechne die Häufigkeit von Stromausfällen mit der Regelmäßigkeit der Archivierung und der Einfachheit dieser Lösung... Für ganz Neugierige (nur zur Info, im Raspbian ist alles schon fertig eingerichtet) https://github.com/ghollingworth/overlayfs
Manuel N. schrieb: > da der Raspberry sehr oft auf die SD-Karte schreibt eMMC (embedded MultiMedia Card) https://de.wikipedia.org/wiki/Multimedia_Card#eMMC https://www.computerweekly.com/de/definition/eMMC-embedded-MultiMedia-Card gibts auch bei mouser: https://www.mouser.de/c/semiconductors/memory-ics/emmc/
kai schrieb: > eMMC (embedded MultiMedia Card) Könntest du noch kurz umreißen, wie du es an einen Pi anbinden würdest, und worin du die Vorteile gegenüber einfacheren Lösungen siehst?
Lothar M. schrieb: > Da musste ich doch grade nachschauen. Und finde Bedenkliches: ich hatte > im ab Mitte Juni 2021 die Samsung EVOPlus 32GB MB-MC32G im Test. Und was > sag ich: wwider Erwarten ist die erste der 4 Karten schon nach 2 Monaten > auffällig geworden (eine read only Datei hatte sich verändert) und 2 > Wochen später waren alle kaputt. Ich muss also meine Empfehlung etwas > revidieren :-/ OK, überzeugt. Ich verwende jetzt nur noch Dateisysteme mit eingebauten Prüfsummen. BTW, loggst du eigentlich die Dauer der Laufzeit deiner SD-Card-killer Scripte? Die Datenrate ändert sich ja im Laufe des (kurzen) Lebens einer gestressten SD Karte. Vielleicht kann man die als Frühindikator verwenden? Ansonsten gilt: Alles wird gut! NVMe wandert in die (µ)SD Karte die über ein oder zwei PCIe Lanes angebunden wird. (SD Express)
Samsung fanboy schrieb: > BTW, loggst du eigentlich die Dauer der Laufzeit deiner SD-Card-killer > Scripte? Ich messe die Bootdauer. > Die Datenrate ändert sich ja im Laufe des (kurzen) Lebens einer > gestressten SD Karte. > Vielleicht kann man die als Frühindikator verwenden? Nein, das kann man nicht. Auf jeden Fall nicht reproduzierbar. Allein schon, wenn du so eine Karte für ein paar Monate ohne Spannung liegen lässt, wirst du nach dem Wiedereinstecken merken, dass die Karte langsam und mit "Housekeeping" beschäftigt ist. Denn dann parst die Karte das ganze Flash durch und kopiert die Blöcke um, deren Referenzzellen grenzwertig sind. > Vielleicht kann man die als Frühindikator verwenden? Hatte ich schon erwähnt, dass die Glyn-Karten (rudimentäres) SMART können? Dort steht dann als Prozentzahl drin, wie "gut" sich die Karte (bezogen auf die maximalen Schreibzyklen des Flashs) noch fühlt. Tatsächlich kommt das Lebensende aber deutlich später. Und dann zeigt ein anderer Zähler an, dass es mit der Karte zu Ende geht. Der Prozentanzeige würde ich also das Attribut "Frühindikator" geben und den hochlaufenden Zähler als "Karte tauschen!" ansehen.
Angehängte Dateien:
-
SanDisk.jpg
67 KB
Seit Erscheinen des RaspberryPi 1B (und das ist viele Jahre her) im Einsatz. An drei Tagen pro Woche für jeweils sechs Stunden (ca. 1000h/Jahr) ist das Himbeerchen aktiv.
Norbert schrieb: > (ca. 1000h/Jahr) ist das Himbeerchen aktiv. Und was wird da wie oft drauf gespeichert? Wird das System zwischen den Aktivitätsphasen ausgeschaltet? Und zuvor korrekt heruntergefahren? BTW: 1000h sind im Grunde nicht viel, denn das sind grade mal 60 Tage bei Zweischichtbetrieb...
Lothar M. schrieb: > Norbert schrieb: >> (ca. 1000h/Jahr) ist das Himbeerchen aktiv. > Und was wird da wie oft drauf gespeichert? Feste Blöcke. Pro Di,Do,Sa jeweils von 30-50 Geräten á16MiB (12MiB Nutzdaten + 4MiB FEC mit Reed-Solomon codes für Paranoide und Prüfsummen) Also 1440MiB … 2400MiB pro Woche (oder ~~ jeden Monat einmal komplett beschreiben) Plus das, was das OS in den sechs Stunden Aktivität macht (aber kein logging) > Wird das System zwischen den Aktivitätsphasen ausgeschaltet? > Und zuvor korrekt heruntergefahren? Ja. Über eine Schaltung mit einem AT90S4433. Einschalten: 3 Sekunden grünen Knopf drücken. Ausschalten:3 Sekunden roten Knopf drücken nebst Aktivitätsprüfung. Da weit und breit kein Netz zur Verfügung steht, Stromversorgung über 2 dicke Bleibatterien mit gutem, altem linearem Spannungsregler LM317, auf 5.1V eingestellt. Läuft seit ca. acht bis neun Jahren problemlos (RPi 1B, 256MiB RAM) Insgesamt sicher nicht gerade eine übermäßige Belastung der SD, aber wir sind mit dem Ergebnis zufrieden.
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.