Caramon2
Lieutenant
- Registriert
- Jan. 2004
- Beiträge
- 864
Hallo!
Vor fast genau 3 Jahren habe ich mir eine ext. 512 GB Surfire Bunker SSD gekauft, wo eine Verbatim Vi550 S3 verbaut war.
Ich nutze sie als PVR-SSD an meinem Santreceiver: Also Aufnahme, schneiden und oft auch Recoding (inkl. DeLogo) zur Platzersparnis, wenn ich es mir nicht sofort ansehen möchte: Da hat sich schon eine ziemliche Menge angesammelt.
Also hohe Schreiblast und inzwischen hoher Datenbestand, der von SSD-Controller gelegentlich umgeschaufelt wird, um ihn aufzufrischen. Außerdem habe ich sie schon ein paar mal komplett neu aufgesetzt: Um die bestmögliche Formatierung zu ermitteln (ntfs mit 16k Cluster - da der Satreceiver leider nur Windows-Dateisysteme unterstützt), aber auch 2x, weil ntfs sich mal wieder geschrottet hatte.
Die Partitionierung (hinten lasse ich immer etwas frei: für Tests, usw. Außerdem bevorzuge ich "glatte" Partitionsgrößen):
"Laufwerke"-Leistungstest (man kann die Lücke für den MFT gut erkennen - die Geschwindigkeit ist durch USB3 begrenzt):
Da die für die Preisklasse einen sehr guten Eindruck macht und in den Jahren auch nicht langsamer wurde, habe ich mir letzten Monat noch eine als 2. int. SSD gekauft: Für DVB-Temp (Zwischenschritte der Videobearbeitung) und um schnell Sicherungen erstellen/aktualisieren zu können:
Dort sichere ich das laufende System direkt (sozusagen als Zwischenschritt) und übertrage das bei Gelegenheit auf die "richtigen" Sicherungen auf ext. HDDs. - Der Vorteil gegenüber früher (als direkt auf die ext. HDDs gesichert habe) ist, dass ich so auf mehrere/alle Platten parallel sichern kann: Das wäre vorher eine schlechte Idee gewesen, da es aus dem laufenden System heraus zu Konflikten hätte kommen können.
Um das zu verdeutlichen, hatte ich mal alle Sicherungsplatten angeschlossen und aktualisiert, angefangen bei der langsamsten:
Durch die neue SSD würde das insgesamt 18,5 Min. dauern, da ich auch dann mit der langsamsten beginne, aber schon währenddessen auch die Sicherungen auf den anderen Platten durchführen kann. - Inzwischen übrigens alle xfs-formatiert, da viel robuster als btrfs. - btrfs nutze ich wegen der zStd-Komprimierung und automatischen async-discard nur noch auf SSDs.
Relevant ist, dass die alte nur 6,3 GiB SLC-Cache und anschließend noch mit 103,7 MiB/s beschreiben wird, während die neue 74,25 GiB SLC-Cache hat, dafür anschließend nur noch mit 42,5 MiB/s beschrieben wird. - Also anderer Controller und vermutlich sogar QLC statt TLC.
Die Partitionierung, nachdem ich die neue 512 GB Verbatim Vi550 S3 inkl. der Sicherungen fertig eingerichtet hatte:
Aber schon nach dem ersten beschreiben sah der Leistungstest deutlich schlechter als bei der alten aus (das ist nur die Lesegeschwindigkeit und natürlich hatte ich ihr vorher mehr als genug Zeit gelassen, den SLC-Cache umzukopieren und interne Arbeiten abzuschließen):
12 Tage später (die Sicherungen inzwischen natürlich mehrfach (je nach Bedarf) aktualisiert):
Und eben:
Zumindest ist es seit letztem Mal nicht noch viel schlechter geworden (wie letztes Jahr bei den Intenso-SSDs. s. u. !!!) und es werden keine Fehler gefunden:
Da ich effektiv nur 10 € *) bezahlt habe, lohnt es sich nicht, etwas zu unternehmen: Ich brauche die SSD, abgesehen davon funktioniert ist unauffällig, ein Austauschmodell hätte sicherlich das gleiche Problem und eine teure (die vielleicht auch nicht viel besser ist), wäre es mir nicht wert.
*) für 25 € bei Notebooks-Billiger im Angebot, abzgl. 15 € Gutschein von letztem Jahr, den ich endlich nutzen wollte: Ich musste sogar einen neuen Code anfordern, da der alte nicht mehr angenommen wurde.
Die aktuelle Belegung:
Es ist mehr geworden, da ich auch dort jeweils mehrstufig sichere, aber nicht viel, weil ich unverändertes per Hardlinks übernehmen lasse (die Sicherungsskripte habe ich angehängt - Obacht: Die sind natürlich an mein System angepasst, also nicht einfach starten.):
Die Belegung im Detail:
"Referenced" wäre die Belegung, würde ich keine Hardlinks nutzen, "Uncompressed" die tatsächliche Datenmenge und "Disk Usage" was durch die zStd-Komprimierung wirklich belegt ist.
Wobei die Standardeinstellung der Komprimierung ist, bei jeder Datei stichprobenartig zu erkennen, ob sie komprimierbar ist und sie ansonsten gleich unkomprimiert zu speichern. - Dabei gehen ihr zwar ein paar GiB durch die Lappen, aber im Verhältnis zur Gesamtmenge (da hauptsächlich Videos, Bilder, Musik und anderes nicht komprimierbares) lohnt sich der viel höhere Aufwand von "force-zstd" nicht.
-----------------
Die Intenso-SSDs sahen zuletzt so aus (das ist die reine LESE-Geschwindigkeit: nichts mit schreiben, SLC-Cache, TLC-Limitierung und es gab auch keine anderen, parallelen Zugriffe auf die SSDs):
Die 240 GB war mein Systemlaufwerk, die 960 GB meine ext. bootfähige Kopie inkl. Sicherung meines Videoarchivs.
Ich hatte sie Anf. 2023 bei Amazon gekauft, die Reklamation wurde anstandslos angenommen und ich habe mein Geld zurück bekommen.
Wichtig:
Nach einem Secure-Erase hatten die SSDs wieder die volle Geschwindigkeit, waren dann aber schon nach Tagen wieder komplett im Keller.
Damit das reproduzierbar blieb (ich wollte sie ja nicht als "geprüft und ohne Fehler" zurück bekommen), musste ich die Daten also drauf lassen.
Bei meiner Home-Partition war das kein Problem, da sowieso verschlüsselt und alle anderen Partitionen habe ich verschlüsselt formatiert und die Daten wieder drauf kopiert. Anschließend habe ich noch alle Header mit Zufallszahlen überschrieben, so dass die Daten nicht mal mit Passwort wiederherstellbar waren.
Btw:
Auch davon hatte ich ein ca. 2 Jahre älteres Modell, was einen sehr guten Eindruck gemacht hat und trotz intensiver Nutzung weiterhin macht:
Relevant: Bei allen Intensos (wenn vollständig leer) umfasste der SLC-Cache 1/3 der kompletten Kapazität: Also haben alle den komplettem freien Flashspeicher als SLC-Cache genutzt und da 1/3 der Kapazität, hatten auch die neuen Intensos TLC-Flashspeicher verbaut.
Ich teste das manuell im Terminal:
Nachdem der SLC-Cache voll ist, lasse ich es noch ein paar GiB weiter laufen, um einen brauchbaren Mittelwert für "nach dem SLC-Cache" zu bekommen und breche dann ab.
Achtung: Der Schreibtest überschreibt das Laufwerk mit Zufallszahlen! Wenn irgendwas drauf war, ist das natürlich weg.
Wer hiervon etwas selbst ausprobieren will, macht das auf eigene Gefahr.
Vor fast genau 3 Jahren habe ich mir eine ext. 512 GB Surfire Bunker SSD gekauft, wo eine Verbatim Vi550 S3 verbaut war.
Ich nutze sie als PVR-SSD an meinem Santreceiver: Also Aufnahme, schneiden und oft auch Recoding (inkl. DeLogo) zur Platzersparnis, wenn ich es mir nicht sofort ansehen möchte: Da hat sich schon eine ziemliche Menge angesammelt.
Also hohe Schreiblast und inzwischen hoher Datenbestand, der von SSD-Controller gelegentlich umgeschaufelt wird, um ihn aufzufrischen. Außerdem habe ich sie schon ein paar mal komplett neu aufgesetzt: Um die bestmögliche Formatierung zu ermitteln (ntfs mit 16k Cluster - da der Satreceiver leider nur Windows-Dateisysteme unterstützt), aber auch 2x, weil ntfs sich mal wieder geschrottet hatte.
Die Partitionierung (hinten lasse ich immer etwas frei: für Tests, usw. Außerdem bevorzuge ich "glatte" Partitionsgrößen):
"Laufwerke"-Leistungstest (man kann die Lücke für den MFT gut erkennen - die Geschwindigkeit ist durch USB3 begrenzt):
Da die für die Preisklasse einen sehr guten Eindruck macht und in den Jahren auch nicht langsamer wurde, habe ich mir letzten Monat noch eine als 2. int. SSD gekauft: Für DVB-Temp (Zwischenschritte der Videobearbeitung) und um schnell Sicherungen erstellen/aktualisieren zu können:
Dort sichere ich das laufende System direkt (sozusagen als Zwischenschritt) und übertrage das bei Gelegenheit auf die "richtigen" Sicherungen auf ext. HDDs. - Der Vorteil gegenüber früher (als direkt auf die ext. HDDs gesichert habe) ist, dass ich so auf mehrere/alle Platten parallel sichern kann: Das wäre vorher eine schlechte Idee gewesen, da es aus dem laufenden System heraus zu Konflikten hätte kommen können.
Um das zu verdeutlichen, hatte ich mal alle Sicherungsplatten angeschlossen und aktualisiert, angefangen bei der langsamsten:
Code:
2,5" 500 GB, 5400 rpm,btrfs: 18,5 Min.
2,5" 500 GB, 7200 rpm, xfs : 12,5 Min.
3,5" 1 TB, 7200 rpm, xfs : 13,0 Min.
3,5" 1 TB, 7200 rpm, xfs : 12,0 Min.
2,5" 320 GB, 7200 rpm, xfs : 11,0 Min.
---------
67,0 Min.Relevant ist, dass die alte nur 6,3 GiB SLC-Cache und anschließend noch mit 103,7 MiB/s beschreiben wird, während die neue 74,25 GiB SLC-Cache hat, dafür anschließend nur noch mit 42,5 MiB/s beschrieben wird. - Also anderer Controller und vermutlich sogar QLC statt TLC.
Die Partitionierung, nachdem ich die neue 512 GB Verbatim Vi550 S3 inkl. der Sicherungen fertig eingerichtet hatte:
Aber schon nach dem ersten beschreiben sah der Leistungstest deutlich schlechter als bei der alten aus (das ist nur die Lesegeschwindigkeit und natürlich hatte ich ihr vorher mehr als genug Zeit gelassen, den SLC-Cache umzukopieren und interne Arbeiten abzuschließen):
12 Tage später (die Sicherungen inzwischen natürlich mehrfach (je nach Bedarf) aktualisiert):
Und eben:
Zumindest ist es seit letztem Mal nicht noch viel schlechter geworden (wie letztes Jahr bei den Intenso-SSDs. s. u. !!!) und es werden keine Fehler gefunden:
Code:
UUID: b81a6d35-e988-4b01-9151-4a064fe8525f
Scrub started: Sun Nov 10 13:20:51 2024
Status: finished
Duration: 0:10:24
Total to scrub: 170.65GiB
Rate: 280.04MiB/s
Error summary: no errors found*) für 25 € bei Notebooks-Billiger im Angebot, abzgl. 15 € Gutschein von letztem Jahr, den ich endlich nutzen wollte: Ich musste sogar einen neuen Code anfordern, da der alte nicht mehr angenommen wurde.
Die aktuelle Belegung:
Es ist mehr geworden, da ich auch dort jeweils mehrstufig sichere, aber nicht viel, weil ich unverändertes per Hardlinks übernehmen lasse (die Sicherungsskripte habe ich angehängt - Obacht: Die sind natürlich an mein System angepasst, also nicht einfach starten.):
Die Belegung im Detail:
Code:
Processed 7630746 files, 762685 regular extents (4086275 refs), 4337462 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 87% 166G 191G 571G
none 100% 153G 153G 411G
zstd 34% 12G 37G 160GWobei die Standardeinstellung der Komprimierung ist, bei jeder Datei stichprobenartig zu erkennen, ob sie komprimierbar ist und sie ansonsten gleich unkomprimiert zu speichern. - Dabei gehen ihr zwar ein paar GiB durch die Lappen, aber im Verhältnis zur Gesamtmenge (da hauptsächlich Videos, Bilder, Musik und anderes nicht komprimierbares) lohnt sich der viel höhere Aufwand von "force-zstd" nicht.
-----------------
Die Intenso-SSDs sahen zuletzt so aus (das ist die reine LESE-Geschwindigkeit: nichts mit schreiben, SLC-Cache, TLC-Limitierung und es gab auch keine anderen, parallelen Zugriffe auf die SSDs):
Die 240 GB war mein Systemlaufwerk, die 960 GB meine ext. bootfähige Kopie inkl. Sicherung meines Videoarchivs.
Ich hatte sie Anf. 2023 bei Amazon gekauft, die Reklamation wurde anstandslos angenommen und ich habe mein Geld zurück bekommen.
Wichtig:
Nach einem Secure-Erase hatten die SSDs wieder die volle Geschwindigkeit, waren dann aber schon nach Tagen wieder komplett im Keller.
Damit das reproduzierbar blieb (ich wollte sie ja nicht als "geprüft und ohne Fehler" zurück bekommen), musste ich die Daten also drauf lassen.
Bei meiner Home-Partition war das kein Problem, da sowieso verschlüsselt und alle anderen Partitionen habe ich verschlüsselt formatiert und die Daten wieder drauf kopiert. Anschließend habe ich noch alle Header mit Zufallszahlen überschrieben, so dass die Daten nicht mal mit Passwort wiederherstellbar waren.
Btw:
Auch davon hatte ich ein ca. 2 Jahre älteres Modell, was einen sehr guten Eindruck gemacht hat und trotz intensiver Nutzung weiterhin macht:
Relevant: Bei allen Intensos (wenn vollständig leer) umfasste der SLC-Cache 1/3 der kompletten Kapazität: Also haben alle den komplettem freien Flashspeicher als SLC-Cache genutzt und da 1/3 der Kapazität, hatten auch die neuen Intensos TLC-Flashspeicher verbaut.
Ich teste das manuell im Terminal:
Code:
# Laufwerk (Vorsicht!):
lw=/dev/sdX
# read:
sudo dd status=progress if=$lw iflag=direct of=/dev/null bs=64M
# write (/tmph/ = RAM-Disk (tmpfs) mit "huge=always"):
dd if=/dev/urandom of=/tmph/rnd.raw bs=64M count=16
q=0;z=0;while [ $q -lt 1 ];do echo -n $z"*1G: ";sudo dd if=/tmph/rnd.raw of=$lw oflag=direct bs=64M count=16 oseek=$((z*16)) && z=$((z+1)) || q=1;done
# dann sofort löschen, damit der genutzte SLC-Cache nicht mehr umkopiert werden muss:
sync;blkdiscard -v $lw && sleep 1m;blkdiscard -vp16M $lwAchtung: Der Schreibtest überschreibt das Laufwerk mit Zufallszahlen! Wenn irgendwas drauf war, ist das natürlich weg.
Wer hiervon etwas selbst ausprobieren will, macht das auf eigene Gefahr.
