Moin ihr Lieben, schon seit Längerem habe ich mehrere Raspberry PIs an verschiedenen Stellen im Haushalt am Werkeln. Z.b. als Hühnerklappen-Überwachung, am Solar-Wechselrichter und am Stromzähler. Die meiste Zeit Ideln die kleinen Kerlchen vor sich hin. Leider fallen die Teile bei mir aber immer nach ein ein paar Monaten/Jahren aus. Meistens ist die SD Karte dann nicht mehr lesbar oder das Dateisystem ist korrupt. Und das, obwohl ich Marken SD Karten im Einsatz habe. Welche Langzeit-Erfahrungen habt ihr da gemacht? Gibt's die "eine" super SD Karte die die vielen Schreibzyklen ab kann? Oder doch überall eine SSD dran hängen? Für den richtig professionellen Einsatz sind mir die kleinen Kerlchen durch diese Ausfälle echt zu instabil. Nichts ist blöder, als wenn das Filesystem am der SDCard am Arsch ist und das mühevoll zusammengefrickelte Python-Script weg. Da muss es doch eine professionellere Lösung geben, abgesehen vom ziehen von Backups?
Schreibzugriffe auf die sdcard minimieren. Zum Beispiel in dem man schreibdaten auf einen USB-Stick schreibt. Falls es den zerlegt ist zumindest nicht dein Linux kaputt.
Florian L. schrieb: > Schreibzugriffe auf die sdcard minimieren. Zum Beispiel in dem man > schreibdaten auf einen USB-Stick schreibt. Falls es den zerlegt ist > zumindest nicht dein Linux kaputt. Ist aber nur ein Workaround. Das eigentliche Problem ist dadurch nicht gelöst. Erstmal ist die Frage, was geht da schief? Wird die SD Karte zu Tode geschrieben? Eher nicht, denn nach Neuformatierung halten die wieder recht lange durch. Gehen die durch falsche Bedienung kaputt? Sprich SDIO oder SPI Fehler am Bus? Oder gibt es da Spannungsschwankungen und die SD Karten mögen das nicht?
Ich hatte auch immer Probleme mit den SD Karten und nichts hat geholfen. Ich habe jetzt mal eine USB-Platte angeschlossen und lasse den RasPi davon booten. Ob das langfristig stabil ist werde ich noch rauskriegen.
Andras H. schrieb: > Erstmal ist die Frage, was geht da schief? Genau das ist die Frage. > Wird die SD Karte zu > Tode geschrieben? Eher nicht, denn nach Neuformatierung halten die > wieder recht lange durch. Wenn das wirklich so ist, dann liegt's mit an Sicherheit grenzender Wahrscheinlichkeit an Unzulänglichkeiten in der Stromversorgung. Sprich: hartes Abschalten ohne vorheriges Herunterfahren oder sporadische Resets durch Spannungs-Drops (was effektiv dasselbe bewirkt).
Der H. schrieb: > Nichts ist blöder, als wenn das > Filesystem am der SDCard am Arsch ist und das mühevoll > zusammengefrickelte Python-Script weg. Du meine Güte, es ist Mittwoch! Noch nicht einmal am Donnerstag sollte so etwas geschrieben werden. Dafür sind hier traditionell die Freitage vorgesehen.
Der H. schrieb: > Leider fallen die Teile bei mir aber immer nach ein ein paar > Monaten/Jahren aus. Meistens ist die SD Karte dann nicht mehr lesbar > oder das Dateisystem ist korrupt. Und das, obwohl ich Marken SD Karten > im Einsatz habe. Es gibt industrial Grade SD-Cards, die dann eine bessere (groessere) Lebenserwartung haben. Wenn Du aber ein anderes Problem hast (z.B. irgendwelche elektrischen Stoerungen auf dem Raspberry [z.B. Motorstoerungen]) oder eine Stromversorgung, die nicht so gut ist, hilft Dir das sehr wenig. > Welche Langzeit-Erfahrungen habt ihr da gemacht? Gibt's die "eine" super > SD Karte die die vielen Schreibzyklen ab kann? Oder doch überall eine > SSD dran hängen? Du koenntest natuerlich auf einen USB-Stick schreiben, auf einen weiteren Linux-Rechner oder Deine Daten per MQTT verteilen. > Für den richtig professionellen Einsatz sind mir die kleinen Kerlchen > durch diese Ausfälle echt zu instabil. Die Raspberry-Pi waren nie fuer den Dauerbetrieb gedacht, ausser den Compute-Moduls. > Nichts ist blöder, als wenn das > Filesystem am der SDCard am Arsch ist und das mühevoll > zusammengefrickelte Python-Script weg. Wenn die Skripte wichtig waren, hast Du ein Backup gemacht. Hast Du kein Backup, waren die Daten nicht wichtig. So einfach ist das. Plattenplatz ist billig. > Da muss es doch eine professionellere Lösung geben, abgesehen vom ziehen > von Backups? z.B. ein Entwicklung mit den Compute-Modules. Aufbau pruefen, Netzfilter einbauen, hochwertige Netzteile verwenden. Gruesse Th.
Andras H. schrieb: > Florian L. schrieb: > Ist aber nur ein Workaround. Das eigentliche Problem ist dadurch nicht > gelöst. Erstmal ist die Frage, was geht da schief? Wird die SD Karte zu > Tode geschrieben? Eher nicht, denn nach Neuformatierung halten die > wieder recht lange durch. Gehen die durch falsche Bedienung kaputt? > Sprich SDIO oder SPI Fehler am Bus? Oder gibt es da > Spannungsschwankungen und die SD Karten mögen das nicht? Ja, das ist die Frage. Auf den Raspberries läuft bei mir lediglich das standard Raspbian OS ohne GUI. Dazu meistens ein Python script dass gelegentlich was in eine MySQL DB schreibt. Der Hühner PI hängt draußen -> im Winter kalt, im Sommer warm. Aber trocken! Könnte das was ausmachen? Eigentlich doch nicht wirklich, oder? Wir reden hier von -5°C - max. 30°C
Der H. schrieb: > Ja, das ist die Frage. Auf den Raspberries läuft bei mir lediglich das > standard Raspbian OS ohne GUI. Dazu meistens ein Python script dass > gelegentlich was in eine MySQL DB schreibt. Mit InnoDB? Dann weisst Du ja, wo geschrieben wird. Und ja, es gibt andere (bessere) Loesungen auch mit dem Raspi (suche mal nach Memory-DB). Gruesse Th.
Thomas W. schrieb: > Der H. schrieb: > >> Ja, das ist die Frage. Auf den Raspberries läuft bei mir lediglich das >> standard Raspbian OS ohne GUI. Dazu meistens ein Python script dass >> gelegentlich was in eine MySQL DB schreibt. > > Mit InnoDB? Dann weisst Du ja, wo geschrieben wird. Und ja, es gibt > andere (bessere) Loesungen auch mit dem Raspi (suche mal nach > Memory-DB). > > Gruesse > > Th. Hi Thomas, ich denke ja, Innodb. Aber hey, kann es wirklich die Ursache sein, dass ich da alle 2 Minuten zwei Messwerte in eine Tabelle schreibe? Andere Leute lassen doch ihre gesamte Homematic o.Ä. auf einem Raspberry Pi laufen, da wird doch sekündlich irgend was in die DB gespeichert.
Als Spannungsversorgung hängt bei mir ein normales, kleines Stecker-Schaltnetzteil dran. Der ChickenPI wird von einem DC/DC Wandler versorgt. Verwendet ihr bei euren Projekten das Originalnetzteil? Oder gibt's da eventuell fertige kleine DC-Netzfilter? Norbert schrieb: > Der H. schrieb: >> Nichts ist blöder, als wenn das >> Filesystem am der SDCard am Arsch ist und das mühevoll >> zusammengefrickelte Python-Script weg. > > Du meine Güte, es ist Mittwoch! > Noch nicht einmal am Donnerstag sollte so etwas geschrieben werden. > Dafür sind hier traditionell die Freitage vorgesehen. Heute läuft auch alles...wahrscheinlich knallt's dann am Freitag :D Thomas W. schrieb: >> Nichts ist blöder, als wenn das >> Filesystem am der SDCard am Arsch ist und das mühevoll >> zusammengefrickelte Python-Script weg. > > Wenn die Skripte wichtig waren, hast Du ein Backup gemacht. Hast Du kein > Backup, waren die Daten nicht wichtig. So einfach ist das. Plattenplatz > ist billig. Ja, das mache ich inzwischen auch automatisch. Die gesamte SDCard wird gedumpt und auf ein NAS kopiert. Läuft auch und lässt sich wieder her stellen, ist halt nur immer zwei Stunden Arbeit bis das dann wieder schnurrt.
Spätestens seit der Raspi 4b out of the box von USB-SSD Booten kann, ist das Thema SD-Kartenverschleiß doch gegessen. Oliver
Moin, - ich weiss ja nicht, wie der Aufbau, Stoerungen oder die Stromversorgung Deines Aufbaus ist. Wenn Du Inno-DB benutzt, schreibst Du (je nach Aufbau Deiner Tabellen) ein Teil der Buffer immer an der gleichen Sektoren. Ob das bei Deinem Aufbau relevant ist, weiss ich natuerlich nicht. Man muss sich nur im klaren sein, dass bei einer ACID-Datenbank sehr viele Daten hin- und herbewegt werden (kein Problem bei Rotationsplatten). Bei einer SSD gibt es sehr gute, leistungsfaehig Algorithmen fuer das Wear-Leveling. Bei Deiner SD-Card hast Du (wenn Du richtig Glueck hast) ein paar Spares. Moeglichkeiten waere z.b. SSD am USB angeklemmt oder auf einen anderen Rechner speichern. Aber erstmal wuerde ich die Stromversorgung angucken (der RaspberryPi ist ein wenig pingelig). Gruesse Bonne Chance Th. P.S.: Memory-Tables (oder heap) sind natuerlich weg wenn Strom weg ist.
Der H. schrieb: > Da muss es doch eine professionellere Lösung geben, abgesehen vom ziehen > von Backups? Klar. Wenn es unbedingt ein Pi sein muss, dann ein Compute Module 4 zusammen mit so einem Trägerboard: https://www.berrybase.de/mini-base-board-a-fuer-raspberry-pi-compute-module-4 Da kannst Du dann entweder ein CM4 mit Onboard EMMC nehmen (die sind wesentlich zuverlässiger), und/oder Du packst eine M.2 Typ M 2242 NVME SSDs in den Slot auf der Unterseite. Sowas läuft dann ewig. SSDs haben üblicherweise viel mehr Schreibzyklen und sind auch deutlich schneller. Andere Möglichkeit wäre z.B. ein Olimex Lime2, ein Beaglebone AI-64, ein Jetson Orin Nano oder irgendwas anderes mit EMMC und/oder einem Slot für eine SSD. Im Gegensatz zu einem Pi kann man die Alternativen auch tatsächlich kaufen. fchk
Raspberrys gegen ESP tauschen. Alle zwei Minuten nen Messwert in eine Datenbank schreiben bekommen die auch hin.
Der H. schrieb: > Moin ihr Lieben, > schon seit Längerem habe ich mehrere Raspberry PIs an verschiedenen > Stellen im Haushalt am Werkeln. Z.b. als Hühnerklappen-Überwachung, am > Solar-Wechselrichter und am Stromzähler. Mein Gott, was für ein Overkill! Das kann EINER allein und langweit sich noch! > Welche Langzeit-Erfahrungen habt ihr da gemacht? Gibt's die "eine" super > SD Karte die die vielen Schreibzyklen ab kann? Oder doch überall eine > SSD dran hängen? Schreibzugriffe auf praktisch Null begrenzen. Und ein stabiles Netzteil, das nicht einfach mal ausgeht, das mag Linux nicht so. Beitrag "Raspberry Pi langlebigere SD-Karte, wie?" Beitrag "Raspberry Pi Read-Only SD-Karte einschränkungen?" Beitrag "Eure Erfahrungen mit SD-Karten"
Der H. schrieb: > Welche Langzeit-Erfahrungen habt ihr da gemacht? Ich habe ein Set (Raspi, Netzteil Gehäuse, SD Karte) original von der Raspberry Pi Foundation gekauft. Das lief bei mir 2 Jahre im Dauerbetrieb, um die Verfügbarkeit von ein paar Webservern zu protokollieren. Das funktionierte ohne Probleme. SD Karten werden in sehr unterschiedlicher Qualität verkauft. Leider sieht man es ihnen von außen nicht an. Deswegen empfehle ich dir, eine vorinstallierte Karte von der Raspberry Pi Foundation zu kaufen. Diese sind gründlich geprüft. Es lohnt sich nicht, da wegen 5 Euro zu knausern. Dann spielt es auch eine ganz große Rolle, wie viele Schreibzugriffe deine Programme so machen. Das Betriebssystem hat in seiner Minimalinstallation eine vernünftige Grundkonfiguration. Aber wenn du Software installierst, die temporäre Dateien, Auslagerungsspeicher oder Logfiles benutzt, verschließt die Karte unter Umständen rasant schnell. Der H. schrieb: > Nichts ist blöder, als wenn das > Filesystem am der SDCard am Arsch ist und das mühevoll > zusammengefrickelte Python-Script weg. > Da muss es doch eine professionellere Lösung geben, abgesehen vom ziehen > von Backups? Wer Backups verweigert, dem ist nicht zu helfen. Du könntest du die Software von einem Server via TFTP laden und die Protokolle zum Server liefern. Der Raspi braucht dann gar kein eigenes Speichermedium.
Stefan F. schrieb: > Wer Backups verweigert, dem ist nicht zu helfen. Ich habe zum Beispiel backup, aber es ist doch halt Nervig, dass man die SD Karte erst mal raus nimmt. Dann zum PC wandert. Da wieder beschreibt. Wieder zum RPi wandert und hofft dass alles klappt. Man müsste das nicht machen, wenn der RPi nicht die SD Karten fressen würde.
Andras H. schrieb: > Man müsste das nicht machen, wenn der RPi nicht die SD Karten fressen > würde. Man müsste das auch nicht machen, wenn man nicht die billigste der billigsten Hardware verwendet. You get what you pay.
Der H. schrieb: > Hühnerklappen-Überwachung Also für Hühnerklappen-Überwachung und ähnliche Applikationen fallen mir bessere und billigere Lösungen ein. Den Stromfrass eines Raspberry Pi würde ich auch gerne vermeiden. Linux für Hühnerklappen-Überwachung, OMG.
Wastl schrieb: > allen mir bessere und billigere Lösungen ein Wir schaffen nicht einmal bei einer RPi, dass die SD Karten nicht kaputt gehen. Wie sollen wir dann bei andere Lösungen andere Probleme lösen können? Es ist relativ einfach zu sagen, dass andere Lösungen bestimmt besser sind. Aber der Poster hat nun mal Probleme mit einer RPi, und es gibt schon anscheint bestehende Projekte die damit laufen. Und die Erwartung dass ein RPi die SD Karten nicht kaputt macht ist auch nicht unrealistisch. Eigentlich müsste man erstmal ein Setup haben wo das Problem viel öfters kommt als alle paar Monate oder Jahre. Bzw. den Setup so gestalten, dass die SD Karte nicht geschrieben wird, sondern nur gelesen. Alles andere soll extern, oder verworfen werden. Brauch man eh nicht, kann halt auch ein RAM Disk sein. Die SD Karte sollte von hoher Qualität sein. Wenn das Problem immer noch besteht, dann kann man gucken woran es noch liegen könnte. Bus Fehler? Oder Spannungsschwankungen?
Das Problem mit den SD-Karten habe ich nicht mehr seit dem ich darauf eine Swap-Partition angelegt habe. D.h. das sonst vorhandene Swap-File hat eine niedrigere Prioritaet bekommen. Das wurde zwar im Forum immer als Loesung niedergemacht, aber funktioniert seit Jahren.
Andras H. schrieb: > Ich habe zum Beispiel backup, aber es ist doch halt Nervig, dass man die > SD Karte erst mal raus nimmt. Dann zum PC wandert. Da wieder beschreibt. > Wieder zum RPi wandert und hofft dass alles klappt. Ja, traurig, wenn einem nix anderes einfällt. Andras H. schrieb: > Wir schaffen nicht einmal bei einer RPi, dass die SD Karten nicht kaputt > gehen. Wie sollen wir dann bei andere Lösungen andere Probleme lösen > können? Wer ist wir? Von Dir auf andere zu schließen ist schon dreist. > Und die Erwartung dass ein RPi die SD Karten nicht kaputt macht ist auch > nicht unrealistisch. Wir haben seit Jahren in der Firma zum Eigenbedarf für verschiedenste Aufgabe Raspberrys laufen, ohne SD Ausfälle. Irgendwas machen wir da wohl im Gegensatz zu Dir anders. > ein RAM Disk sein. Die SD Karte sollte von hoher Qualität sein. > Wenn das Problem immer noch besteht, dann kann man gucken woran es noch > liegen könnte. Bus Fehler? Oder Spannungsschwankungen? Warum kaufst Du nicht gleich vernünftig SD-Karten und geeignete Netzteile ein? Dann brauchst Du nicht Zeit mit Fehlersuche verschwenden. Es ist eigentlich immer die gleiche Leier: Billigste Karte, Karte zu klein, ungeeignete Karte, miserable Einkaufsquelle, unterdimensionierte Spannungsquelle oder eine Kombination davon. Aber dann die Foren volljammern.
Andras H. schrieb: > Wastl schrieb: >> allen mir bessere und billigere Lösungen ein > > Wir schaffen nicht einmal bei einer RPi, dass die SD Karten nicht kaputt > gehen. Wie sollen wir dann bei andere Lösungen andere Probleme lösen > können? > Eigentlich müsste man erstmal ein Setup haben wo das Problem viel öfters > kommt als alle paar Monate oder Jahre. Bzw. den Setup so gestalten, dass > die SD Karte nicht geschrieben wird, sondern nur gelesen. Alles andere Das ist kein Problem: Nimm ein billiges Netzteil (so ca. 1A * 4.9V = 4,9W) und lass das Ding ein bischen laufen. Die Maschine wird dann mehrmals rebooten, beim jeden Mal ist vielleicht das Filesystem hin. Sehr viel Swapping ist auch nicht gut fuer die SD-Card. Wenn ich mir das Netzteil der Raspberry Foundation angucke (die Warze ist Standard, aber die Ausgangsspannung ist 5.3V, das Verbindungskabel Warze - Raspberry hat einen deutlich hoeheren Querschnitt als das Billig-Zeug). MySQL (oder MariaDB) stresst bei InnoDB die Platte auch: z.B. ein paar gute INNER JOIN bei grossen Datensaetzen. Mit diesen drei Sachen kannst Du den Fehler sehr schnell reproduzieren :-) Also, kein Problem. Gruesse Th. P.S.: hier hatte irgendwer mal berichtet: Drei Wochen Dauerschreiben bringt auch Qualitaetsprodukte an die Wand :-)
Thomas W. schrieb: > P.S.: hier hatte irgendwer mal berichtet: Drei Wochen Dauerschreiben > bringt auch Qualitaetsprodukte an die Wand :-) Jaja, die Forenschreiber und ihre Qualitätsprodukte :-( Fast jeder ernstzunehmende Hersteller hat dauerbeschreibbare SD-Karten im Angebot. Eine 32GB Samsung Pro Endurance kostet im Media Markt 11€ und wird mit 2 Jahren dauerbeschreibbarkeit, z.B. durch Überwachungskameras, beworben. WD Purple 64GB kostet 13€ und wird entsprechend mit 32TBW beworben. Natürlich fließt da optimierend der Umstand mit ein, daß große Blöcke geschrieben werden. Trotzdem dürften die einiges Aushalten. Ich habe zumindest noch keine kaputt bekommen.
Michael L. schrieb: > Thomas W. schrieb: >> P.S.: hier hatte irgendwer mal berichtet: Drei Wochen Dauerschreiben >> bringt auch Qualitaetsprodukte an die Wand :-) > > Jaja, die Forenschreiber und ihre Qualitätsprodukte :-( Das war vor einigen Jahren... > Fast jeder ernstzunehmende Hersteller hat dauerbeschreibbare SD-Karten > im Angebot. Eine 32GB Samsung Pro Endurance kostet im Media Markt 11€ > und wird mit 2 Jahren dauerbeschreibbarkeit, z.B. durch > Überwachungskameras, beworben. Das ist richtig, daher gehe ich davon aus dass die Spannungsversorgung verbesserungsfaehig ist. Gruesse Th.
Bei mir läuft in einem RPi seit 4-5 Jahren none stop eine Samsung Pro Endurance. Keine Probleme bisher. Und ich hab keine Maßnahmen getroffen, irgendwas von Logging abzuschalten oder auf Ramdisk oder sonst was. Openhab ist da drauf. Eine Weile auch der Musik-Streamingserver.
Wurde hier schon Raspi-USV genannt? Meine Raspi haben Uptimes von 4 Jahren. Safe Shutdown war schon immer Pflicht. Habe allerdings einen knappen Schuhkarton USV durchprobiert bis eine passte ... Runout
Wastl schrieb: > Der H. schrieb: >> Hühnerklappen-Überwachung > > Also für Hühnerklappen-Überwachung und ähnliche Applikationen > fallen mir bessere und billigere Lösungen ein. Den Stromfrass > eines Raspberry Pi würde ich auch gerne vermeiden. > > Linux für Hühnerklappen-Überwachung, OMG. Es gibt eine Menge Menschen mit einem Smartphone für 600-1.500€, die können außer mühsam telefonieren und mal ein WA Nachricht verschicken nix auf die Reihe. Was den Strom angeht, da verbrauchen irgendwelche Baumarkt-Funksteckdosen im Haushalt jeden Tag pro Stück 0,7 - 1,4 Watt… Das wollte ich jetzt nicht schön reden, sondern daran erinnern, dass es ja um die SD-Cards ging. Meine 2 RPi Zero 1W laufen seit 2018 im Dauerbetrieb mit FHEM, ein paar Skripte die ein paar Daten von diversen Seiten holen - ohne Probleme. Das einzige was ich gemacht hab, die ganze sekündliche Loggerei/Schreiberei zu unterbinden und die Daten in Dateien zu schieben - keine Datenbank im klassischen Sinne. Und 1x pro Tag werden die Dateien per Skript auf‘s NAS geschoben. Und als Netzteil verwende ich irgendein „grünes Netzteil“, in Summe zwischen 0,8 bis 1,6W - mit 3 USB-Sticks (Z-Wave, Signalduino, CUL).
Michael L. schrieb: > Fast jeder ernstzunehmende Hersteller hat dauerbeschreibbare SD-Karten > im Angebot. Eine 32GB Samsung Pro Endurance kostet im Media Markt 11€ > und wird mit 2 Jahren dauerbeschreibbarkeit, z.B. durch > Überwachungskameras, beworben. > WD Purple 64GB kostet 13€ und wird entsprechend mit 32TBW beworben. Bedeutet das, dass jeder Block gerade mal 32TB/64GB=500-mal beschrieben werden kann? Das erscheint mir nicht besonders viel zu sein. Die Karte ist UHS Speed Class 1, sollte also mit 10MB/s sequentiell beschreibbar sein. Nutzt man diese Geschwindigkeit tatsächlich aus, ist nach 32TB/(10MB/s)=3.200.000s, also nach 37 Tagen Schluss. Dass die Karte so stark beansprucht wird, kann schnell passieren, wenn bspw. durch einen Softwarefehler der Speicher zuläuft und der Rechner in ein Dauer-Swapping übergeht. Gerade bei einem Embedded-System wie der Hühnerklappenüberwachung merkt man das evtl. erst, wenn die Karte schon fast ausgelutscht ist. Einen Swap-Bereich auf einem im Dauereinsatz befindlichen Raspberry einzurichten, halte ich ohnehin für Unfug, erst recht bei einer Anwendung wie der Hühnerklappenüberwachung, die vermutlich nur einen verschwindend kleinen Anteil des verfügbaren RAMs benötigt. Ich würde sogar noch einen Schritt weiter gehen, und jegliche Schreibzugriffe auf das Medium mit der Linux-Installation unterbinden. Das bedeutet u.a., dass es weder ein /var- noch ein /tmp-Verzeichnis gibt. Wenn die Karte nur bei der Installation und bei Software-Updates beschrieben wird, sollte sie deutlich länger als ein paar Jahre halten, sofern sie nicht vorher vom Blitz getroffen wird. Irgendwelche Anwendungsdaten (bspw. Messwerte), die unbedingt gespeichert werden müssen, werden am besten per Netzwerk auf ein externes Medium übertragen, das für den Dauerbetrieb ausgelegt ist. Wenn das nicht möglich ist, bietet sich ein lokaler USB-Stick an, der von Zeit zu Zeit geprüft und ggf. ausgetauscht wird. So ist die Linux-Installation mit der Anwendungssoftware auch ganz gut vor Stromausfällen geschützt.
Yalu X. schrieb: > Michael L. schrieb: >> WD Purple 64GB kostet 13€ und wird entsprechend mit 32TBW beworben. > > Bedeutet das, dass jeder Block gerade mal 32TB/64GB=500-mal beschrieben > werden kann? Das erscheint mir nicht besonders viel zu sein. Das ist knapp unterhalb des Bereichs, bis zu dem Samsung auf eine 970 Evo Plus Garantie gibt, nämlich bei einer 1TB SSD bis zu 600TBW, also 600 mal beschrieben. Das ist bei TLC nun mal so. > Die Karte ist UHS Speed Class 1, sollte also mit 10MB/s sequentiell > beschreibbar sein. Nutzt man diese Geschwindigkeit tatsächlich aus, ist > nach 32TB/(10MB/s)=3.200.000s, also nach 37 Tagen Schluss. Dann willst Du gar nicht ausrechnen, wie schnell theoretisch bei der EVO Plus "Schluss" ist, wenn Du die mit maximaler Schreibgeschwindigkeit dauerbespaßt. Kauf lieber keine SSDs.
Thomas T. schrieb: > Habe allerdings einen knappen > Schuhkarton USV durchprobiert bis eine passte > ... > Runout Und magst du deine Weisheit mit uns teilen? :)
Stefan F. schrieb: > Andras H. schrieb: >> Man müsste das nicht machen, wenn der RPi nicht die SD Karten fressen >> würde. > > Man müsste das auch nicht machen, wenn man nicht die billigste der > billigsten Hardware verwendet. You get what you pay. Eben nicht! Der Raspi frisst früher oder später auch teure Karten. Welche "teure" würdest du denn genau empfehlen? Samsung Pro Endurance habe ich jetzt schon mehrfach gelesen. Die von der Raspberry Pi Foundation hab ich allerdings noch nicht probiert. Wastl schrieb: > Der H. schrieb: >> Hühnerklappen-Überwachung > Also für Hühnerklappen-Überwachung und ähnliche Applikationen > fallen mir bessere und billigere Lösungen ein. Den Stromfrass > eines Raspberry Pi würde ich auch gerne vermeiden. > > Linux für Hühnerklappen-Überwachung, OMG. Halloooo? Wie sollen die Nachbarn denn sonst die Klappe per Webinterface öffnen, wenn sie auf der Hühnercam sehen, dass Jemand draußen geblieben ist? ;) (während ich in der Stadt saufen bin) Dieter D. schrieb: > Das Problem mit den SD-Karten habe ich nicht mehr seit dem ich darauf > eine Swap-Partition angelegt habe. D.h. das sonst vorhandene Swap-File > hat eine niedrigere Prioritaet bekommen. > Das wurde zwar im Forum immer als Loesung niedergemacht, aber > funktioniert seit Jahren. Hast du zu dem Thema einen Link? Yalu X. schrieb: > Irgendwelche Anwendungsdaten (bspw. Messwerte), die unbedingt > gespeichert werden müssen, werden am besten per Netzwerk auf ein > externes Medium übertragen, das für den Dauerbetrieb ausgelegt ist. Wenn > das nicht möglich ist, bietet sich ein lokaler USB-Stick an, der von > Zeit zu Zeit geprüft und ggf. ausgetauscht wird. So ist die > Linux-Installation mit der Anwendungssoftware auch ganz gut vor > Stromausfällen geschützt. Das mit dem USB-Stick ist eine gute Idee! Ich finde halt, gerade die Möglichkeit, Daten zu speichern (z.B. Werte aus einem Wurzel-Stromzähler) machen den Raspi so charmant und brauchbar. Dem Thema "saubere Spannungsversorgung" werde ich in Zukunft etwas mehr Aufmerksamkeit widmen. Dadurch ließen sich schon beim Atmel µC einige Probleme, z.B. mit überschriebenen eeprom Werten vermeiden. Vielleicht ist's ja auch die Kombi aus hochwertiger Karte, minimierten Schreibzugriffen und stabiler Spannungsversorgung?
Hast Du mal mit
1 | sudo dumpe2fs -h /dev/mmcblk0p2 |
geguckt, was unter „Lifetime writes“ ausgegeben wird? Möglicherweise musst Du die Partition (hinter /dev/…) noch auf Deine SD Card anpassen.
Der H. schrieb: > Der Raspi frisst früher oder später auch teure Karten Jahrelanger Betrieb von SD Karten als reine Sysdisk muss kein Problem sein.
Uwe D. schrieb: > geguckt, was unter „Lifetime writes“ ausgegeben wird? Das hab ich eben gemacht. Wie gesagt, 24/7 Betrieb mit Openhab. Karte: 32GB Samsung Pro Endurance. "Last write time" irritiert mich allerdings.
1 | Filesystem created: Wed Jun 27 03:08:02 2018 |
2 | Last mount time: Mon May 22 08:29:40 2023 |
3 | Last write time: Wed Oct 3 10:15:15 2018 |
4 | Mount count: 109 |
5 | Maximum mount count: -1 |
6 | Last checked: Wed Oct 3 10:48:12 2018 |
7 | Check interval: 0 (<none>) |
8 | Lifetime writes: 927 GB |
Hallo, Andras H. schrieb: > Stefan F. schrieb: >> Wer Backups verweigert, dem ist nicht zu helfen. > > Ich habe zum Beispiel backup, aber es ist doch halt Nervig, dass man die > SD Karte erst mal raus nimmt. Dann zum PC wandert. Da wieder beschreibt. > Wieder zum RPi wandert und hofft dass alles klappt. ich nehme da die Reservekarte, schreibe das Backup am PC drauf und laufe einmal zum RasPi. > Man müsste das nicht machen, wenn der RPi nicht die SD Karten fressen > würde. Hier läuft ein Pi4 mit u.a. FHEM drauf, SD-Kartenfehler würde ich auf max. 1x pro Jahr schätzen. Der FHEM-Ordner wird nachts auf einem USB-Stick am RasPi gesichert. Wurde bisher einmal gebraucht weil es die SQlite Datenbank zerlegt hatte. Geloggt wird nur in für mich sinnvollen Zeitabständen, ich brauche nicht alle Minute aktuelle Temp/Feuchtedaten aus den Räumen im Log. SD-Karten bei mir Samsung, ein Bekannter hat ähnliches zu laufen, der hatte mit SanDisk mehrere Ausfälle nach wenigen Monaten. Netzteil ist hier das RasPi-Netzteil, der RasPi reagiert definitv recht empfindlich auf die Stromversorgung. Es gibt noch einen RasPi3 als OpenVPN-Gateway woanders, der hat in rund 3 Jahren eine SD-Karte "gefressen". Alle diese Anwendungen sind unkritsch für mich und dürften auch mal für einen Tag ausfallen. Gruß aus Berlin Michael
900ss D. schrieb: > "Last write time" irritiert mich allerdings. Das dürfte sich auf den Header selbst beziehen, nicht auf den Inhalt des Filesystems. Ein auch nicht mehr so ganz frischer RasPi eines 24x7 Kiosk-Displays, Typ SanDisk Ultra SC16G:
1 | Last write time: Wed Sep 19 14:40:49 2018 |
2 | Mount count: 37 |
3 | Lifetime writes: 90 GB |
Du kannst auch das erstgenannte Tool (sudo verwenden) hier im LINK https://www.laub-home.de/wiki/Raspberry_Pi_Schreiboperationen_minimieren verwenden und gucken, wer da genau sich mit Schreiben „verlustiert“
Angehängte Dateien:
-
chickenpi_controller.jpg
200 KB -
chickenpi.jpg
250 KB
Uwe D. schrieb: > Hast Du mal mit >
1 | sudo dumpe2fs -h /dev/mmcblk0p2 |
2 | >
|
> geguckt, was unter „Lifetime writes“ ausgegeben wird? > > Möglicherweise musst Du die Partition (hinter /dev/…) noch auf Deine SD > Card anpassen. Das ist interessant, Uwe! Der ChickenPi läuft schon seit Jahren, die anderen erst seit Frühling 23 (Solar): @ChickenPi (16GB Karte) Lifetime writes: 126 GB @wurzelzaehler (10GB Karte) Lifetime writes: 19 GB @GrowattPi (32GB Karte) Lifetime writes: 9 GB Auf dem ChickenPI läuft auch ein kleiner Apache2, der loggt bekanntermaßen recht viel. Das schalte ich auf jeden Fall für die Zukunft aus. 126GB ist schon ne Hausnummer. Wenn ich dann aber die Schreibraten der anderen sehe... mein lieber Herr Gesangsverein! Uwe D. schrieb: > Du kannst auch das erstgenannte Tool (sudo verwenden) hier im LINK > https://www.laub-home.de/wiki/Raspberry_Pi_Schreiboperationen_minimieren > verwenden und gucken, wer da genau sich mit Schreiben „verlustiert“ Cooler Tip! Ich sichere meine PIs über ein shellscript (läuft alle paar tage nachts) auf ein Netzwerk-Share (z.B. NAS). Die gesamte SDCard wird damit gedumpt und kann notfalls "einfach" auf eine neue Karte geflasht werden. Das funktioniert ganz gut automatisch. Habe das Script mal angehängt, vielleicht hilft es Jemandem.
Du kannst auch beim RPZ auch mit log2ram etwas Entspannung bringen, musst Du mal ein biss‘l mit den Werten jonglieren. Ist hier einigermaßen beschrieben: https://www.pcwelt.de/article/1196524/raspberry-pi-schneller-dank-logdateien-im-ram.html Und falls das LOG-Verzeichnis überquillt, hilft das hier beim steuern: https://www.raspberry-pi-geek.de/ausgaben/rpg/2017/06/mit-journalctl-die-systemd-protokolle-auswerten/
Der H. schrieb: > Welche "teure" würdest du denn genau empfehlen? Habe ich bereits geschrieben. > Die von der Raspberry Pi Foundation hab ich allerdings noch nicht > probiert. Tja
Uwe D. schrieb: > sudo dumpe2fs -h /dev/mmcblk0p2 > geguckt, was unter „Lifetime writes“ ausgegeben wird? Bei mir ergibt das: Filesystem created: Sep 2019 Lifetime writes: 2290 GB Und so erzeugst Du eine zusätzlich Swap-Partition: Zuerst die vorhergehende Partition mit gparted verkleinern. Dann auf der Console: $ sudo mkswap /dev/mmcblk0p4 Setting up swapspace version 1, size = 4008432 KiB no label, UUID=xxxx-xxxx-xxx-xxxxx-xxxxx Nun werden alle Swap-Partitionen eingeschaltet. Damit diese Swap-Partition dauerhaft übernommen wird, muss diese in die /etc/fstab eingetragen werden. sudo nano /etc/fstab Die beiden Zeilen wurden ergänzt: /var/swap none swap sw,pri=1 0 0 /dev/mmcblk0p4 none swap sw,pri=5 0 0 Dann diese einschalten mit: $ sudo swapon -a $ sudo swapon NAME TYPE SIZE USED PRIO /var/swap file 100M 0B -1 /dev/mmcblk0p4 partition 3,8G 0B 5
Sollte das "mmc" Tool aus mmc-utils funktionieren, dann steht darin 0x01 für 0-10% der Lebenszeit verbraucht, 0x02 für 10-20% usw.
1 | mmc extcsd read /dev/mmcblk0 | grep -i life |
2 | eMMC Life Time Estimation A [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_A]: 0x03 |
3 | eMMC Life Time Estimation B [EXT_CSD_DEVICE_LIFE_TIME_EST_TYP_B]: 0x03 |
Mein Netbook von 2017 mit 30 GB eMMC als Systemdisk liefert also erst 20-30% verbraucht, obwohl das die ersten 4 Jahre unter Windows recht gut verwendet wurde und mittlerweile etliche Linux-Neuinstallationen mit vollständigem Überschreiben hinter sich hat.
An einem RPi4 läuft eine Crucial M500 SATA mit 120GB, uralt das Teil, mit der Herstellerangabe 72TBW. Nach 2 Jahren 24/7 Betrieb mit 6 aktiven Dockercontainern (FHEM, MariaDB, deCONZ, nodered, …) sind 1,1TBW auf der Uhr. Backups habe ich auch jeden Tag. Also ich wüsste nicht, warum ich mir Sorgen machen müsste. Eine Ersatz-SSD ist auf jeden Fall besser und wäre in kürzester wieder in Betrieb.
Ich frag mich echt was ihr falsch macht, unsere birdcam (ein RPI Zero mit LTE Modul, 0.5A Strom-Peaks beim Senden):
1 | piggy@birdcam:~ $ uptime |
2 | 20:20:35 up 408 days, 9:17, 1 user, load average: 0,65, 0,57, 0,55 |
3 | piggy@birdcam:~ $ sudo dumpe2fs -h /dev/mmcblk0p2 |
4 | dumpe2fs 1.43.4 (31-Jan-2017) |
5 | ... |
6 | Lifetime writes: 261 GB |
SD Karte ist eine SanDisk Industrial 32GB von 2018. Beim letzten (gewollten) Neustart war die uptime ähnlich hoch. Es ist übrigens sehr wichtig die gesamte SD zu nutzen. D.h. die root Partition/Filesystem sollte nach dem Flaschen auf die Größe der SD Karte erweitert werden. Eine SD Karte kennt kein "TRIM" und weis daher nicht, welcher Sektor unbenutzt ist und welcher nicht. Es ist besser wenn das FS die Möglichkeit hat alle Sektoren zu benutzen. Achja, was viele vergessen, auch das Lesen eines NAND Flash-Sektors erzeugt "wear". Nach ca. 10000-100000 Lesezugriffen (flashabhängig) auf den gleichen Sektor muss dieser ebenfalls neu geschrieben werden. D.h. Workloads mit vielen Lesezugriffen tu'n dem Flash ebenfalls weh.
Angehängte Dateien:
Ich benutze seit einiger Zeit nur noch SSDs am Raspi, wenn diese längerfristig laufen sollen. Es gibt da so Adapter, die eine M.2-SSD aufnehmen und direkt an den Raspi geschraubt werden. Die Verbindung erfolgt über eine Art "USB-Brücke", die ohne Kabel, mit Mini-PCB den rechten unteren USB-Port direkt mit dem SSD-Adapter verbindet. Die Einrichtung ist simpel: - für den ersten Start benötigt man eine SD-Karte mit Raspian, fertig konfiguriert (SSH, VNC, WLAN ... alles was sein soll) - der Adapter mit SSD ist angebaut und verbunden - mit dem Onboard-Copy-Tool (steckt im Bereich Tools von Raspian), eine Kopie von der Karte auf die SSD machen - 1 Zeile Terminal: echo program_usb_boot_mode=1 | sudo tee -a /boot/config.txt - Raspi herunterfahren, SD-Karte raus, Neustart ... fertig ... Und es funktioniert bereits mit Raspberry 3B, ein 4er ist nicht unbedingt notwendig.
Andreas M. schrieb: > Eine SD Karte kennt kein "TRIM" Dafür aber ERASE. Und fstrim kann damit etwas anfangen. "Watch SD card wear levelling trim erase in action" https://forums.raspberrypi.com//viewtopic.php?t=229726
1 | Jun 12 00:27:44 xxx fstrim[51235]: /: 191.1 MiB (200404992 bytes) trimmed on /dev/mmcblk0p2 |
2 | Jun 12 00:27:44 xxx fstrim[51235]: /boot: 221.6 MiB (232357888 bytes) trimmed on /dev/mmcblk0p1 |
3 | Jun 12 00:27:44 xxx systemd[1]: fstrim.service: Succeeded. |
Andreas M. schrieb: > Es ist besser wenn das FS die > Möglichkeit hat alle Sektoren zu benutzen. Auch wenn ein Filesystem lediglich die Hälfte des Flash beansprucht, werden bei wear levelling dennoch mit der Zeit alle Flash-Blöcke verwendet.
(prx) A. K. schrieb: > Auch wenn ein Filesystem lediglich die Hälfte des Flash beansprucht, > werden bei wear levelling dennoch mit der Zeit alle Flash-Blöcke > verwendet. Wenn aber z.B nur 4GB von 32GB verwendet werden wird fstrim niemals "ERASE" (Danke für Deinen Hinweis) für die restlichen 28GB ausführen und damit "weiß" die Karte auch nicht, dass diese Blöcke frei sind... fstrim arbeitet immer nur auf der Partition. Kommt natürlich auch ein bisschen auf die Vorgeschichte der Karte an. Ich hatte anfangs noch überlegt statt ext4fs besser f2fs zu verwenden. Der Standard-Kernel des Raspian müsste das eigentlich auch können, Man muss halt auf Dateisystemebene einen Dump machen und die Karte manuell umpartitionieren und den dump zurückspielen. f2fs ist besser für MMCs/SDs geeignet. Bin aber irgendwie nicht dazu gekommen und da es bei mir läuft....
Andreas M. schrieb: > Wenn aber z.B nur 4GB von 32GB verwendet werden wird fstrim niemals > "ERASE" (Danke für Deinen Hinweis) für die restlichen 28GB ausführen und > damit "weiß" die Karte auch nicht, dass diese Blöcke frei sind Man kann vor Neuinstallation per blkdiscard alle Blöcke freigeben.
Uwe D. schrieb: > Du kannst auch das erstgenannte Tool (sudo verwenden) hier im LINK > https://www.laub-home.de/wiki/Raspberry_Pi_Schreiboperationen_minimieren > verwenden und gucken, wer da genau sich mit Schreiben „verlustiert“ Habe das Tool seit heute Mittag laufen lassen. Die meisten Schreibzugriffe kamen wohl vom Journaling wurzelzähler systemd-journald 120 MB jbd2/mmcblk0p2- 35 MB mariadb 54 MB Kann das ohne Bedenken deaktiviert werden?
Andreas M. schrieb: > Ich frag mich echt was ihr falsch macht, unsere birdcam (ein RPI Zero > mit LTE Modul, 0.5A Strom-Peaks beim Senden): . . > SD Karte ist eine SanDisk Industrial 32GB von 2018. Nunja, SanDisk Industrial sind auch heute noch üblicherweise MLC statt TLC wie bei Consumer-Karten. Die erlauben per se schon 4x mal mehr Schreib-/Löschzyklen, haben aber auch ihren Preis. Lohnt sich aber durchaus, da sie auch insgesamt robuster sind.
Der H. schrieb: > Uwe D. schrieb: >> Du kannst auch das erstgenannte Tool (sudo verwenden) hier im LINK >> https://www.laub-home.de/wiki/Raspberry_Pi_Schreiboperationen_minimieren >> verwenden und gucken, wer da genau sich mit Schreiben „verlustiert“ > > Habe das Tool seit heute Mittag laufen lassen. Die meisten > Schreibzugriffe kamen wohl vom Journaling > wurzelzähler > systemd-journald 120 MB > jbd2/mmcblk0p2- 35 MB > mariadb 54 MB > Kann das ohne Bedenken deaktiviert werden? Kommt darauf an was Du damit machen willst. Also ich schränke die Journale auf 256MB ein, da kann ich mit log2ram arbeiten. Bei mir läuft langweiliger Kram - zu 95% headless. Gelegentlich schalte ich mal den Monitor ein. Es ist (glaube ich) wichtiger, dass regelmäßig geguckt wird, wie gesund das System ist und immer Backups gemacht werden. Auf den ressourcenschwachen RPZ 1+2 mit nur 512MB RAM, z.B. die Nistkasten-WebCam, da schränke ich fast alles ein. Das Ding läuft immer gleich und da mache ich auch keine Untersuchungen, wenn mal was nicht geht - da tausche ich wenn überhaupt, dann die ganze Hardware.
Ja ja die systemd Seuche. Lennart weis schon was gut für alle ist. Der Begriff Journaling ist mehrdeutig und wird eigentlich eher für das Filesystem-Journal verwendet.(Was man nicht abschalten will) journald ist ja die logging-Komponente vom systemd. Man kann den so konfigurieren, dass er die logs nur noch im RAM hält. (journald.conf) Ich weis gerade nicht ob ich das gemacht habe oder ob ich auf den guten alten rsyslogd umgestellt habe. Zu mindesten bei letzterem kann man die Logs auch selektiv konfigurieren.
Unser Nachbar schafft seine 20 Hühner ohne Pi und mit NULL µC und PC Erfahrung. Kommt doch mal der Fuchs, freut er sich auf neue Hühner für 5€ das Stück!
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.