UPDATE 31.10.: Amazon Alexa - ioBroker Skill läuft aus ?

[Homoran]

@opensourcenomad sagte in SSD oder HDD:

Das es nicht sein, das man die Flashspeicher in SBC frittiert zeigt Armbian.

das liegt aber IMHO noch an einem weiteren Feature.
Armbian lässt eine bestimmte Anzahl Zellen beim expand ungenutzt, damit diese als reserve dienen können

[OpenSourceNomad]

@homoran said in SSD oder HDD:

das liegt aber IMHO noch an einem weiteren Feature.
Armbian lässt eine bestimmte Anzahl Zellen beim expand ungenutzt, damit diese als reserve dienen können

Das wird defacto keinen großes Einfluss haben. Flashspeicher sind von Haus aus überprovisoniert (haben mehr Speicher als aufgedruckt).
Es gab mal zu Beginn von SSDs so "tolle" tips nicht sie ganze Platte zu partitionieren damit das teil länger hält, ist natürlich reiner Voodoo. Es kommt rein auf die geschrieben bits an.

Was allerdings übel ist bei Flashspeicher, wenn alle Zellen einmal beschrieben sind kann, muss vor einer erneuten Beschreibung erst "aufgeräumt" werden. Das liegt an der Beschaffenheit von Flashspeicher der immer im Blöcken daher kommt.

Es kann z.B. sein das ein Raspberry Pi OS jede 5 Sekunden 1 Byte Logfile schreiben will. Was aber passiert durch die Layer ist das am Ende (jede 5 Sekunden) ein vielfaches geschrieben wird, in diesem Fall wo nur 1 byte geschrieben werden soll, sind es wahrscheinlich 8 oder 16kb (typische flash block Größe). Oben drauf kommt natürlich noch die bekannte write amplification :hammer:

Durch dieses (vereinfachte) Beispiel erkennt man schon den 8-16 tausendfach schnelleren Tod des Flashspeicher :skull:

[Dr. Bakterius]

@laser sagte in SSD oder HDD:

Da muß eben eine größere (2,5 Zoll) SSD dran. Da dauert aber das Lesen/schreiben des Images länger, wenn es die nicht als 32 GB gibt.

Du musst ja nicht die volle Kapazität nutzen. So geht nicht nur das Image-Lesen und -Schreiben schneller, sondern man hat deutlich mehr Reserve-Zellen die eventuell defekt gewordene Speicherzellen ersetzen können. Daher immer die S.M.A.R.T. Werte im Auge behalten!

Ich verwende von meiner 512 GB SSD in meinem NUC auch nur 25% der Kapazität. Der Rest ist einfach nicht partitioniert. Außerdem sollte man da nicht geizen sondern (wie auch @OpenSourceNomad geschrieben hat) etwas mehr in Markenware investieren. Ich bin bisher ganz gut mit Samsung gefahren. Mir ist auch vor einiger Zeit eine SSD (VERBATIM Vi550 S3) im NUC noch innerhalb der Garantiezeit gestorben - war auch eher ein billiges Produkt. Wenigstens gab es das Geld zurück...

[OpenSourceNomad]

@dr-bakterius said in SSD oder HDD:

Ich verwende von meiner 512 GB SSD in meinem NUC auch nur 25% der Kapazität

Wenn du das machen würdest, müsstest du deinen Flashspeicher in einen read-only Modus versetzen nachdem du die ersten 128gb geschrieben hast. Machst du das? Wohl eher nicht...
Dein Flashspeicher ist es auch übrigens total Wurst was du partitonierst und was nicht, das wear-leveling geschieht komplett intern. Anderst als bei Festplatten hast du keinerlei Einfluss welche Zellen beschrieben werden.

@opensourcenomad said in SSD oder HDD:

Es gab mal zu Beginn von SSDs so "tolle" tips nicht sie ganze Platte zu partitionieren damit das teil länger hält, ist natürlich reiner Voodoo. Es kommt rein auf die geschrieben bits an.

Also bitte, wer jetzt noch mal empfiehlt eine SSD nicht ganz zu partionieren bitte dann auch konsequent noch ein Lobeshymne auf ein manuelles IP management sowie ganz wichtig: das aktuellste Schlangenöl :warning:

[Homoran]

@opensourcenomad sagte in SSD oder HDD:

Das es nicht sein muss, dass man die Flashspeicher in SBC frittiert zeigt Armbian

nachdem ich früher fast alles non-Raspis (allein wegen der damals nicht vorhanden RAM-Größe bei RasPis) mit armbian verwendet hatte, habe ich mir wegen der Horrorgeschichten um sterbende Karten den ersten Raspi4 2GB (der 4GB war damals noch nicht wirklich zu bekommen) besorgt und eine ioBroker Installation auf einer 32GB Karte installiert.
Dann habe ich etwa 200 Datenpunkte ganz bewusst mit History (JSON-Dateien) teilweise im Sekundentakt geloggt.
Bis heute habe ich es nicht geschafft diese Karte zu schreddern

[Laser]

Was war das für meine Karte und wann war "damals"? Wie lange läuft das schon so?

[Dr. Bakterius]

@opensourcenomad sagte in SSD oder HDD:

das wear-leveling geschieht komplett intern.

Korrekt. Und bei 520 GB können einfach mehr Zellen als defekt markiert werden als bei 120 GB. Noch dazu wird jede Zelle nur ein Viertel so häufig beschrieben bei gleicher Schreibleistung was ungefähr der vierfachen Lebensdauer entspricht. Also auch wenn man den Platz (vorerst) nicht benötigt, kann man bei einer größeren SSD von einer längeren Lebensdauer ausgehen.

Die kleinere Partition macht das Handling bei Images und beim Clonen einfacher.

[Homoran]

@laser sagte in SSD oder HDD:

Was war das für meine Karte

die ziehe ich jetzt nicht raus

@laser sagte in SSD oder HDD:

wann war "damals"?

als es
@homoran sagte in SSD oder HDD:

den ersten Raspi4 2GB

gab

@laser sagte in SSD oder HDD:

Wie lange läuft das schon so?

seitdem ohne Unterbrechung

[OpenSourceNomad]

@dr-bakterius said in SSD oder HDD:

Noch dazu wird jede Zelle nur ein Viertel so häufig beschrieben bei gleicher Schreibleistung was ungefähr der vierfachen Lebensdauer entspricht.

Nein! Nur weil du weniger partitionierst sinkt doch deine Schreibrate nicht :face_palm:

Die kleinere Partition macht das Handling bei Images und beim Clonen einfacher.

Auch nicht wirklich wahr. Ich komprimierte meine images immer gleich on-the-fly (usbimaher machte möglich :bulb:)

[OpenSourceNomad]

@homoran said in SSD oder HDD:

teilweise im Sekundentakt geloggt.

Mit default commit von 5 Sekunden wird e "nur" alle 5 Sekunden æcht:TM: geschrieben :bulb:

[paul53]

@laser
Meine Maßnahmen für eine hohe Lebensdauer des Massenspeichers:

• SLC Flash (16 GB) - nicht mehr verfügbar, dafür kann man größere SSD mit MLC-Flash verwenden (wear leveling)
• Swapping deaktiviert
• folder2ram für die History und das Verzeichnis /var/log
• Schreibintervall der DB states.json auf 10 Minuten erhöht. DB objects.json wird ohnehin nur selten geschrieben
• USV

Läuft seit ca. 5 Jahren stabil.
Hätte mein RasPi 2 nicht nur 1 GB RAM, würde ich das komplette Verzeichnis iobroker-data mit folder2ram verlagern.

[Laser]

@paul53
So habe ich meine Billig SSD derzeit eingerichtet. Ich warte nun auf den Tod der Karte. Mal sehen, ob diese länger als 2 Jahre hält. In der Zwischenzeit brauch ich natürlich ein Konzept für die sinnvolle Erneuerung. Wird wohl eine Marken SSD 2,5" werden.

[paul53]

@laser sagte: Wird wohl eine Marken SSD 2,5" werden.

Ist zu empfehlen.

[OpenSourceNomad]

@paul53 said in SSD oder HDD:

Schreibintervall der DB states.json auf 10

Aber ext4 weiterhin mit commit Intervall von 5 Sekunden? Irgendeinen speziellen Grund warum du nur das Schreibintervall der DB limitierst und nicht gleich "global" auf dem filesystem?

[paul53]

@opensourcenomad sagte: Grund warum du nur das Schreibintervall der DB limitierst und nicht gleich "global" auf dem filesystem?

Häufiges Schreiben habe ich nur in den Verzeichnissen iobroker-data/history, /var/log und in die Datei states.json festgestellt. Die beiden Verzeichnisse sind nach tmpfs (RAM) verlagert und können dort mit 5-s-Intervall aktuell gehalten werden. Außerdem weiß ich nicht, wo man das commit-Intervall verändern kann, denn meine Linux-Kenntnisse sind sehr bescheiden.

[Dr. Bakterius]

@opensourcenomad sagte in SSD oder HDD:

Nur weil du weniger partitionierst sinkt doch deine Schreibrate nicht

Dann sieh dir doch mal die technischen Daten von unterschiedlich großen SSD der gleichen Reihe an! Ich habe auch nirgends erwähnt, dass die Partitionsgröße mit der Schreibleistung in Zusammenhang steht! Wenn es dir nicht klar ist, dass wenn sich die geschriebene Datenmenge auf die vierfache Anzahl von Speicherzellen verteilt die mögliche zu schreibende Datenmenge und damit die Lebensdauer vervierfacht (so ungefähr), dann denke noch mal darüber nach.

Auch, dass das Clonen auf kleinere Laufwerke mit kleineren Partitionen leichter fallen kann, ist so - kannst mir glauben oder auch nicht. Und weshalb soll die Partition das gesamte LW einnehmen wenn man nur einen Bruchteil davon benötigt? Vergrößern kann man bei Bedarf immer noch.

Wenn du Samsung-SSD nicht kennst: da kann man auch die Menge an Reserveblöcken per Software anpassen (dafür opfert man eben Speicherplatz). Also auch da ist eine größere Platte von Vorteil.

[OpenSourceNomad]

@dr-bakterius said in SSD oder HDD:

und damit die Lebensdauer vervierfacht (so ungefähr), dann denke noch mal darüber nach.

Habe ich und es ist leider immer noch Mumpitz. Der SSD (im Grunde jedem Flashspeicher) ist es total Schnuppe wieviel der "verfügbaren Zellen" du (glaubst) zu partionieren. Die SSD verwendet alle vorhanden Zellen, du hast gar keine Möglichkeit (wie bei den guten alten Festplatten) die verwendeten Zellen zu beeinflussen oder zu limitieren.

Das einzige was deinen Flashspeicher schont ist das Schreibaufkomme zu verringern. Und an meisten "Gewinn" hat wenn man vermeidet das kleinste Chunks (wenige byte) auf den Flash einprasseln. Warum? Weil eine ganze (Flash) Zelle/Page verheizt wird obwohl nur ein Bruchteil davon Nutzdaten enthält.

Veinfacht gesagt (neben den zu schreibenden bits und den flash gibt es auch nämlich auch noch das filesystem dazwischen was mitwerkelt), kannst du dir das vorstellen wie ein leeres Buch :notebook: . Für jeden Eintrag den du machst musst du eine neue Seite :page_facing_up: beschreiben (und löschen geht übrigens nur ganzseitig der ganze Ordner:file_folder:!). Sprich du willst nur eine Zahl oder sonst was notieren und verheizt dafür eine ganze Seite. Besser ist es deine Einträge zu sammeln und dann am Stück wegzuschreiben, denn dann hast du wirklich was gewonnen: Flash Zellen :tada:

Wenn du Samsung-SSD nicht kennst: da kann man auch die Menge an Reserveblöcken per Software anpassen

Flashspeicher ist immer überprovisoniert und eine größere SSD/SD-Karte kann natürlich auch mehr Schreibzyklen wegstecken, ganz einfach weil sie mehr Zellen/Pages zur Verfügung hat :bulb:

Übrigens löst auch das lesen von Daten auf Flashspeicher neue Schreibaktion darauf aus. Das liegt daran das journaling filesysteme wie z.B. ext3 oder ext4 noch Metadaten ablegen, wie z.B. den letzten Zugriff auf eine Datei :boom:

Seriöse Hersteller geben meist ein TBW (tera bites written) o.ä. an, um eine Idee zu bekommen was das teil verkraften sollte. Diese gehen aber immer davon aus das große Daten am Stück geschrieben werden, also immer die (Flash) Seite/Page voll (effizient) beschrieben wird. Wenn jetzt aber immer nur wenige bits in eine Seite geschrieben wird in der eigentlich Platz für 16 tausend bits sind dann sieht es gleich ganz düster aus. :put_litter_in_its_place:

:point_up: und genau das, meine lieben Damen und Herren, ist ziemlich genau das was auf einem Raspberry pi OS mit "Datenbankapplikation" passiert. :grimacing:

[paul53]

@opensourcenomad sagte: Für jeden Eintrag den du machst musst du eine neue Seite beschreiben (und löschen geht übrigens auch nur ganzseitig!).

Das stimmt für das Löschen. Das Schreiben neuer Daten (kleine Mengen) erfolgt in einen noch nicht beschriebenen Bereich innerhalb der noch nicht voll geschriebenen Seite, d.h. die logische Adresse des file system wird in eine andere physische Adresse übersetzt. Je öfter die Daten geschrieben werden, um so schneller ist eine Seite gefüllt und muss gelöscht werden.

[OpenSourceNomad]

@paul53 said in SSD oder HDD:

Das stimmt für das Löschen

Stimmt leider nicht, ich muss mich korrigieren. Gelöscht werden kann nur blockweise und ein block besteht aus mehreren pages.

Das Schreiben neuer Daten (kleine Mengen) erfolgt in einen noch nicht beschriebenen Bereich innerhalb der noch nicht voll geschriebenen Seite

Das war damals:tm: bei Festpatten so, bei Flash von heute ist das leider nicht möglich. Die kleinste Einheit die geschrieben werden kann ist eine page welche typischerweise 4, 8 oder 16kb groß sind :page_facing_up:

Bei einer Festplatte musstest man immer defragmentieren. Bei flash ist das nicht nötig, aber es gibt die garbage collection und TRIM deren Aufgabe es u.a. ist auf Blockebene sauber zu machen. Wenn ein bock nur noch wenige pagesmit Nutzdaten hat werden diese pages (gesammelt aus mehreren blocks) in einen neuen block geschrieben.

[paul53]

@opensourcenomad sagte: Gelöscht werden kann nur blockweise und ein block besteht aus mehreren pages.

Das meinte ich: Ein Erase block fasst einige Blöcke (typisch 4 kB) des File system.