Empfehlung SD-Karte für RaspberryPi

[MichaelN]

Skandal!!1! Da liefert doch tatsächlich einer Beweise.

[jmaus]

Stimmt tatsächlich nicht, die RM schrieb weniger.

Das ist ja hervorragend!

Genau, denn auch das entlarvt dich erneut wieder als jemanden der sowas einfach nur aus einer Laune heraus "raushaut" ohne fundierte technische Kenntnisse aus dem Bereich zu haben oder zu wissen über was du dort so sprichst. Für mich erneut ein weiterer Beweis dafür das dir weiterhin nicht zu trauen ist....

[blackhole]

Für mich erneut ein weiterer Beweis dafür das dir weiterhin nicht zu trauen ist....

Wenn dem SD-Kartensterben bei RM-Installationen jetzt wirklich ein Ende gesetzt ist, nehme ich das gerne so an.

[Baxxy]

Da mich das jetzt allgemein interessiert hat was die RM täglich so auf die SD-Karte schreibt habe ich mal 3 meiner Systeme geprüft.

• Live-Hauptsystem: ~70,7 MB/d (homematic.regadom ~ 13 MB)
• Test-Hauptsystem: ~41,8 MB/d (homematic.regadom ~ 8,2 MB)
• Test-Sekundärsystem: ~ 31,7 MB/d (homematic.regadom ~ 3,8 MB)

Wenn man jetzt "regelmäßiger Updater" ist kommen für jede neue RM-Version ~ 2GB geschriebene Daten dazu.
Macht bei 12 Updates ~ 24 GB/a + ~ 25,5 GB/a (geschrieben Daten Live-Hauptsystem).
In Summe dann ~49,5 GB/a.

Damit wäre dann die genutzte 16GB-Karte etwa 3x komplett beschrieben.

[blackhole]

In Summe dann ~49,5 GB/a.
Damit wäre dann die genutzte 16GB-Karte etwa 3x komplett beschrieben.

So etwas ist in Sachen SD-Kartentod eher weniger interessant.
Die Karten gehen primär schnell kaputt wenn häufig auf die gleichen Dateien (genauer: Zellen) schreibend zugegriffen wird.
Das klassische Beispiel hierfür sind zum Beispiel Datenbankdateien (CCU3 -> RRDs -> von eQ-3 konzeptionierter "Opferstick").

In Sachen RM könnten das auch FSTRIM, Dateisystem-Interna und andere Dinge, die von der Original-Firmware abweichen sein.
Das müsste jedoch einmal genauer von einem RM-Benutzer untersucht werden.

[jmaus]

In Sachen RM könnten das auch FSTRIM, Dateisystem-Interna und andere Dinge, die von der Original-Firmware abweichen sein.

Tut mir leid, aber auch das ist einfach eine von dir in den Raum geworfene Mutmaßung nur um mal wieder gegen RaspberryMatic zu bashen statt hier fundierte bzw. nachhaltige Dinge vorzubringen die so etwas begründen würden. Alleine von dem Punkt das hier im Forum Personen von sterbenden SD-Karten berichten darauf zu schließen das das ein Problem in RaspberryMatic sein muss ist vollkommen zu kurz gedacht. Das Internet ist voll von Berichten über sterbende SD Karten bei verschiedensten Systemen. Und nur weil hier gefühlt weniger CCU3-Firmware Nutzer davon berichten sagt das alleine auch nichts aus. Die Zahlen derer die die RaspberryMatic Firmware einsetzen sind einfach hier im Forum inzwischen vmtl. um einiges höher als die die noch auf die CCU3 Firmware setzen.

Es bleibt also dabei: Die Daten die Baxxy geliefert hat deuten in keinsterweise auf ein erhöhtes Schreibvolumen beim Einsatz von RaspberryMatic hin das im Zusammenhang mit einem gefühlten mehraufkommen von SD-Kartensterben bei Einsatz von RaspberryMatic in Zusammenhang stehen könnte. Und das hätte mich auch ehrlich gesagt sehr überrascht, alleine schon deshalb weil die CCU3 Firmware und die RaspberryMatic Firmware aus der gleichen Hand stammen, nämlich im Grunde aus meiner!

[jp112sdl]

weil die CCU3 Firmware und die RaspberryMatic Firmware aus der gleichen Hand stammen, nämlich im Grunde aus meiner!

Wann ist denn der Bus an mir vorbei gefahren?

Bisher ging ich davon aus, dass die ReGaHss von dir beigesteuert und der gesamte Rest der CCU3 Firmware von eQ-3 gebaut wird.
Wird sie [die CCU3 Firmware] nun auch eine "One Man Show"?

[blackhole]

[jmaus]

Bisher ging ich davon aus, dass die ReGaHss von dir beigesteuert und der gesamte Rest der CCU3 Firmware von eQ-3 gebaut wird.
Wird sie [die CCU3 Firmware] nun auch eine "One Man Show"?

Klar baut eQ3 die CCU3 Firmware selbst zusammen und bringt auch die Releases raus. Ich meinte damit mehr das prinzipielle Grundgerüst bzw. die initiale CCU3 Firmware für die RaspberryPi3 Linie. An der hab ich maßgeblich damals dran gearbeitet und eQ3 hat das dann im Grunde so übernommen und halt "so weitergemacht" bzw. pflegt ab da eben die für sich relevanten Änderungen ein und ich entwickle die RaspberryMatic Linie unabhängig davon weiter. Damals noch mit dem Hintergrund dann ab und an einen sync zu machen. Aber auf Grund der dauerhaft limitierten Manpower bei eQ3 wird da regelmäßig leider nichts draus und so haben sich nun eben zwangsweise dauerhaft zwei Linien entwickelt. Einmal RaspberryMatic das auf moderne Frameworks und ein modernes OS Grundgerüst setzt und dann die CCU3 Firmware die nicht nur mit einer inzwischen maßlos obsoleten buildroot Umgebung daher kommt, sondern auch mit einem veraltetem Linux kernel, etc. Vom Grundgerüst her ist RaspberryMatic und die CCU3 Firmware aber eben eigentlich genau das gleiche und praktisch eben auch aus den selben Händen entstanden...

Und genau deshalb weiss ich auch, dass das was blackhole da bzgl. vermeintlich höhere Belastung von SD-Karten durch RaspberryMatic sich nichts dahinter verbirgt.

[blackhole]

(...) Und genau deshalb weiss ich auch, dass das was blackhole da bzgl. vermeintlich höhere Belastung von SD-Karten durch RaspberryMatic sich nichts dahinter verbirgt. (...)

Wenn du so argumentierst, war das hier ja auch nicht wirklich nötig:

Eins jedoch habe ich in der letztern offiziellen RM Version noch verbessert. Inzwischen wird das userfs mit der mountoption "commit=30" gemountet. Das sollte bewirken das tendenziell noch weniger regelmäßige Schreiboperationen passieren, denn standardmäßig ist für ext4 das commit interval auf 5 sekunden gestellt, d.h. spätestens alle 5 sekunden schreib es veränderungen aus dem Cache auf das darunterliegende Medium (z.B. SD-Karte). Mit "commit=30" sollten sich also tendenziell Schreiboperationen wenn dieser nahe der 5 sek. stattfinden auch besser zeitlich verteilen und somit die SD-Karten weiter schonen.

Wie auch immer, letztendlich ist mir das alles auch egal, solange das SD-Kartensterben endlich aufhört.
Ich bin guter Dinge, dass Du am richtigen Rädchen gedreht hast und/oder noch drehen wirst.