SSD oder HDD
-
@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
-
@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
) -
@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
-
@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. -
@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. -
@laser sagte: Wird wohl eine Marken SSD 2,5" werden.
Ist zu empfehlen.
-
@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?
-
@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.
-
@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.
-
@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 ganzseitigder 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. 
-
@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.
-
@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
blockbesteht aus mehrerenpages.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 pagewelche typischerweise 4, 8 oder 16kb groß sindBei 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
bocknur noch wenigepagesmit Nutzdaten hat werden diesepages(gesammelt aus mehrerenblocks) in einen neuenblockgeschrieben. -
@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.
-
@paul53 said in SSD oder HDD:
Ein Erase block fasst einige Blöcke (typisch 4 kB) des File system.
Bitte nicht
file system layerundflash layerdurcheinander bringen. Ich spreche hier gerade ausschließlich von letzteren
Sowohl das
file systemals auch derflashhabenblock's, allerdings haben die außer dem Namen nichts gemeinsam. -
@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.
-
@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
-
@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
-
@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.
-
@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.
-
@opensourcenomad Ja und? Kannst du oder willst du nicht verstehen? Es ist schon alles gesagt, was du damit machst bleibt dir überlassen...
