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

[Samson71]

@laser sagte in SSD oder HDD:

Hat jemand Erfahrungen mit 2,5 Zoll HD's? Läuft am Raspi4 USB3. Wie lange wird so ein Teil halten? (WD Blue).

An einer WD Blue wirst Du auch nicht so lange Freude haben. Ich habe jedenfalls weder mit WD Blue noch mit den WD Green gute Erfahrungen gemacht. Für den 24/7 Betrieb würde ich wenn dann WD Red nehmen. Die wiederum laufen zuverlässig. Alternativ Seagate Ironwolf. Die ältesten Platten laufen jetzt ca. 6 Jahre im 24/7 Betrieb.

[Homoran]

@samson71 sagte in SSD oder HDD:

An einer WD Blue wirst Du auch nicht so lange Freude haben

ich nehme an @Laser meint die SSD.

[wendy2702]

@homoran sagte in SSD oder HDD:

@samson71 sagte in SSD oder HDD:

An einer WD Blue wirst Du auch nicht so lange Freude haben

ich nehme an @Laser meint die SSD.

WD Blue gibt es auch als SSD.

Ich habe die WD Red jetzt seit ca. 6 Jahren 24/7 laufen und eine WD Blue seit ca. 4 Jahren… bisher ohne Probleme.

SSD Im Proxmox von Transcend 240GB

[Samson71]

@homoran sagte in SSD oder HDD:

ich nehme an @Laser meint die SSD.

Stimmt, vermutlich hast Du recht. Aber auch da würde ich bei 24/7 Betrieb zu einer WD Red o. Seagate Ironwolf greifen. Auch wenn die dann deutlich mehr kostet.

[OpenSourceNomad]

@opensourcenomad said in SSD oder HDD:

Und was läuft für ein OS drauf? Leider sind z.B. die default settings von raspiOS (oder wie sich das offizielle zwischenzeitlich nennt) ein ziemlicher flash killer. Und zwar nicht nur der SD Karte sondern auch der SSD.

Um noch mal auf die Ursache zu kommen

Raspberry Pi OS kommt mit swap sowie einem ext4 filesystem mit einem commit interval von nur 5 Sekunden. Wozu das führt zeigt u.a. eindrucksvoll dieses Forum. Am laufenden Band verrecken den Leute ihre Flashspeicher.

Das es nicht sein muss, dass man die Flashspeicher in SBC frittiert zeigt Armbian. Meine Orange Pi's laufen seit vielen Jahren ohne einen einzigen SD-Karten Ausfall/Defekt. Möglich machts ein commit interval von 600, log2ram, tmpfs... https://docs.armbian.com/#performance-tweaks

Wenn es die Raspberry Foundation schon nicht schafft ordentliche default Einstellungen zu haben, sollte man vielleicht wenigstens die Anleitungen hier anpassen damit die Leute ein bisschen länger Spass haben bevor der Speicher aufgibt...

[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

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

[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

[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

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.