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

[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

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 )

[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

[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 . Für jeden Eintrag den du machst musst du eine neue Seite beschreiben (und löschen geht übrigens nur ganzseitig der ganze Ordner!). 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

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

Ü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

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.

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

[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 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

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.

[OpenSourceNomad]

@paul53 said in SSD oder HDD:

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

Bitte nicht file system layer und flash layer durcheinander bringen. Ich spreche hier gerade ausschließlich von letzteren

Sowohl das file system als auch der flash haben block's, allerdings haben die außer dem Namen nichts gemeinsam.

[Dr. Bakterius]

@opensourcenomad sagte in SSD oder HDD:

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.

Wie bereits geschrieben: bei Samsung kann man das. Mit deren Software "Samsung Magician" kann man das Over Provsioning - also die Reservezellen - selbst konfigurieren. Bei anderen Herstellern wahrscheinlich auch.

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

Und nichts anderes habe ich geschrieben. Nur weil du einen halben Roman als Antwort verfasst, bedeutet das nicht, dass du verstehst was andere geschrieben haben.

[OpenSourceNomad]

@dr-bakterius said in SSD oder HDD:

bedeutet das nicht, dass du verstehst was andere geschrieben haben.

Es ist immer schwierig (und gefährliches Halbwissen bzw. Märchen sind leider weit verbreitet, auch in diesem Forum) wenn nicht alle ein bestimmtes "Grundwissen" über ein Thema haben. Ich versuche hier das, nicht sehr triviale Thema,
möglichst simplifiziert darzustellen.

Und das wie von dir, aber auch von @Homoran vorgebrachte Märchen wenn weniger partioniert wird hält die SSD länger ist halt nicht wahr und eine Sage aus der Anfangszeit der SSDs (wobei sogar ein Kern Wahrheit darin steckt, zumindest bevor es TRIM gab).

Einzig die geschrieben bits und bytes zählen, da diese die Flashzellen altern lässt

[Homoran]

@opensourcenomad sagte in SSD oder HDD:

und eine Sage aus der Anfangszeit der SSDs (wobei sogar ein Kern Wahrheit darin steckt, zumindest bevor es TRIM gab).

das ist durchaus möglich.
Ich habe das Wissen aus der Anfangszeit von Armbian (als es noch nicht einmal so hieß) aus etwa 2013-2015.
Und mich seitdem auch nicht mehr um Weiterbildung bemüht.

Das war auch noch die Zeit als unter WIN keine Differenzierung in SSD und HDD gemacht wurden und alle Platten erbarmumngslos defragmentiert wurden, was zum schnellen Tod von SSDs führte

[Dr. Bakterius]

@opensourcenomad sagte in SSD oder HDD:

Und das wie von dir, aber auch von @Homoran vorgebrachte Märchen wenn weniger partioniert wird hält die SSD länger ist halt nicht wahr

Und noch einmal: das habe ich so nie geschrieben! Vielleicht liest du meine Beiträge noch einmal und wenn du danach immer noch meinst, dass ich das behauptet habe, solltest du mal am sinnerfassenden Lesen arbeiten.

[OpenSourceNomad]

@dr-bakterius said in SSD oder HDD:

Und noch einmal: das habe ich so nie geschrieben!

@dr-bakterius said in SSD oder HDD:

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

@dr-bakterius said in SSD oder HDD:

Ich verwende von meiner 512 GB SSD in meinem NUC auch nur 25% der Kapazität. Der Rest ist einfach nicht partitioniert.

@dr-bakterius said in SSD oder HDD:

Und bei 520 GB können einfach mehr Zellen als defekt markiert werden als bei 120 GB.

Und noch einmal: Es ist völlig irrelevant wieviel du partitionierst und was nicht. Es zählt einzig allein das Schreibaufkommen und nur weil du nur 120GB von deinen 520GB partitionierst hast du eben nicht automatisch ein geringeres Schreibaufkommen.