Bigeagle
Lt. Commander
- Registriert
- Nov. 2008
- Beiträge
- 1.624
Schnellfazit: Die Seagate hat sehr wahrscheinlich SMR und schafft bis zu 238 MB/s. Die WD hat wahrscheinlich kein SMR aber 'nur' bis zu 217 MB/s. Beide werden reichlich warm im Kunststoffgehäuse. Bei den Dateisystemen kommt es sehr darauf an was, unter welchem OS und mit welchen tuningoptionen man schreibt. Lesetests liefen nur unter Linux und sind allgemein langsamer als das schreiben. Wer Windows nutzt sollte vermutlich zur WD greifen da SMR schnell unangenehm wird. Unter Linux scheint es als sei Btrfs die Lösung und mit kompression wirds stellenweise sogar schneller als im synthetischen Benchmark.
Die Festplattenpreise sind nun leider auch gestiegen, also habe ich zum ersten mal in den sauren Apfel der fertig-externen gebissen anstatt interne HDDs und Gehäuse extra zu kaufen. Der Preisunterschied war recht erheblich. Seagate zeigt auch warum das die schlechtere Option ist mit wahrscheinlich nicht ausgewiesenem SMR.
Amazon hat praktisch auf Polsterung verzichtet, nur an einer Seite gab es Knüllpapier. Oben, unten, rechts, links und 'hinten' lagen die inneren Kartons direkt am äußeren an und natürlich hatte dieser eine deutlich eingedrückte Ecke die eine etwas rauere Handhabung vermuten lässt. Da ist mir ein spezialisierter Hardwarehändler lieber, Mindfactory, Alternate usw hatten da meiner Erfahrung nach fast immer angepasste Verpackungen und mir ist die dicke, mehrschichtige Luftpolsterfolie mit Klebeband um die blanke HDD bei Mindfactory irgendwie lieber als z.b. der relativ steife Kunststoff der die einzige Stoßdämpfung für die WD darstellte.
Ich hatte da schon den Gedanken "Das hast du davon Festplatten bei Amazon zu bestellen."
Aber scheint alles ok zu sein, also ist das vielleicht auch übertriebene Sorge.
Zunächst einmal habe ich grundlegende Funktionstests gemacht und einen 'extended' Selftest per SMART laufen lassen. Das war nicht so einfach wie es hätte sein können, denn unter Linux funktioniert SMART nicht out of the box für die Seagate per smartctl und die WD betrachtet einen laufenden Selbsttest nicht als ausreichenden Grund nicht die Spindel anzuhalten und sich in den Tiefschlaf zu begeben.
Die Seagate brauchte einen wechsel vom 'uasp' treiber auf den älteren 'usb' treiber, dann gibts auch volle SMART funktionalität per smartctl. Vielleicht ginge das auch wenn man das von smartctl verwendete protokoll korrigiert, doch ich hatte nicht den Mut da durchzuprobieren bis etwas funktioniert. Am Ende bricke ich die Platte oder das Gehäuse. Erzwingt man den scsi modus gibt es immerhin die Identifikationsdaten auch mit 'uasp' treiber, was die Zuordnung beim ständigen neu formatieren deutlich entspannter macht.
Zu WD könnte man hier sagen dass alles wie erwartet funktioniert, jedoch gibt es die für mich nicht nachvollziehbare entscheidung im eigenen (Windows)tool die Elements Reihe von der SMART Erkennung auszuschließen, selbst wenn die Platte und das Gehäuse diese Möglichkeiten offensichtlich bieten.
Die Testdauer von rund 30-40 Stunden ist gewöhnungsbedürftig. Die Temperaturen liegen bei 50-55° C im Betrieb und unter Last.
Beide Platten bieten eine eher unangenehme Geräuschkulisse, ein recht hohes summen und eine der beiden fiept offenbar oberhalb meines Hörbereichs. Das Gehäuse der Seagate setzt gelegentlich mit der HDD zum duett an wenn beide sich auf eine Resonanzfrequenz einigen. Ein berühren mit dem Finger genügt um das zu stoppen, was aus meiner Sicht deutlich macht dass das vermeidbar wäre.
Die WD dagegen hat ein stetiges klacken, bestehend aus zwei verschiedenen Klacklauten in unterschiedlichen Intervallen soweit ich das feststellen konnte. Ganz ohne Aktivität von außen wohlgemerkt. Vielleicht schreibt die ihr Temperaturlog für SMART alle 5 sekunden auf die Platter.
Kommentar eines Freundes der noch hohe Frequenzen hört war sinngemäß 'Die eine Festplatte gibt Tinnitus und die andere furzt.'
Für den vermeintlichen Anwendungsfall einer einfachen Speichererweiterung für den Schreibtisch finde ich das reichlich unglücklich.
CrystalDiskMark unter Win 11 mit NTFS und aktiviertem Schreibcache für die Platten - was keine rolle spielen sollte für den Benchmark. Auffällig ist schon mal der deutliche Unterschied beim zufälligen Lesen. Die schreibleistung sieht bei beiden so ähnlich aus dass man nicht auf die Idee kommt dass eine der Platten SMR haben könnte.
Ursprünglich hatte ich nur vor noch ein paar einfache kopiertests unter Windows 10 (alter PC), Win 11 und Linux zu machen bevor ich die beiden ihrer geplanten Verwendung zuführe. Doch die Ergebnisse waren so unerwartet und aus meiner Sicht eigenartig dass ich noch mehr gemacht habe.
Doch was nimmt man für einen möglichst realitätsnahen Test? Große Dateien wie Videos sind vergleichsweise uninteressant, die schreibt man ein mal und liest danach nur noch mit relativ niedrigen Anforderungen an die Geschwindigkeit. Doch für ein naives 'ich will ein Backup von dem und dem Ordner' bräuchte es etwas das gemischte Daten bietet und gleichzeitig groß genug ist um die Ergebnisse nicht zu sehr durch caches zu verfälschen. Der Spieleordner auf einer der SSDs im alten PC schien genau das zu sein was ich suchte. Rund 380 GB mit Unterordnern voller weniger, großer Dateien und solchen die zehntausende in überschaubarer Größe bieten.
Baldurs Gate 3, Duke Nukem Forever, ELEX, Endless Sky, Mechwarrior Online (etwas älterer patchstand), Mount & Blade Warband mit einigen Mods, Silent Hunter 3, Elder Scrolls Online (älterer patchstand) und ein zip des M&B Ordners in älterer Fassung als Backup für irgendetwas.
Schien mir genug von allem dabei zu sein und für eventuelle Zusatztests mit kompression und deduplikation sind solche 'echten' Daten geeigneter als sich etwas aus /dev/zero und /dev/urandom zu ziehen. Mit der Größe war und bin ich immer noch nicht sicher, aber das ist definitiv genug um nicht im Cache der Platten zu versickern und dauert auch so schon lange genug.
Der Anfang war ein einfaches shellscript für robocopy das noch kurz genug ist um es kurz vorzustellen.
Genau genommen war der Anfang nur ein robocopy aufruf, allerdings wurde schnell deutlich dass ich auch wissen will welcher der unterschiedlichen 'subtests' wie schnell ist.
Das (bash)script für Linux ist etwas größer und komplexer, das liegt für interessierte im Anhang. Das soll auch eher als Beispiel dienen und nicht als fertiges Script für eigene Benchmarks. Da sind keine Sicherungen, keine Fehlerbehandlung, ein aufruf eines subscripts das mit root rechten den cache leert bevor der lesetest beginnt und Aufrufe für Programme die evtl nicht jeder installiert hat drin. Vor allem aber keine Sicherungen gegen Fehler! Am Ende wird der als Argument übergebene Zielordner mittels 'rm -r' rekursiv gelöscht, wer da einen existierenden Ordner mit Inhalt angibt hat hoffentlich ein Backup.
Als erstes habe ich unter Win 10 (da lagen die Testdaten auf einer 2 TB Samsung 870 Evo) getestet wie groß der Einfluss der Protokollierung von Robocopy ist. Erstmal nur mit der Seagate. 5675 Sekunden für alles mit Auflistung der kopierten Dateien (aber ohne Verzeichnisse) und 5447 Sekunden ohne jegliche Auflistung. Grund genug im weiteren Verlauf darauf zu verzichten, ich will ja schließlich nicht messen wie schnell die Textausgabe des Terminals ist.
Die mittlere Schreibrate war allerdings unterirdisch mit rund 69, bzw 72 MB/s. Das war unerwartet langsam. Doch da exFAT auch nur ein besseres FAT32 ist das ohne journaling wahrscheinlich brav sequentiell für jede Datei den Eintrag in der Dateitabelle macht und die Daten schreibt bedeutet das eben viel hin und her für den Schreib-lesekopf. Mit dem Schreibcache sah das schon besser aus mit 2244 Sekunden (rund 175 MB/s)
Soweit klar, wie schon Crystaldiskmark zeigte ist die Seagate etwas schneller. Die erste Überraschung zeigte sich als ich die Tests auf Win 11 wiederholte. Mit Schreibcache da exFAT ohne viel zu langsam ist als dass ich das ohne in betracht ziehen würde.
Doch während die Seagate da eine ähnliche Leistung ablieferte (172-174 MB/s) war die WD aus nicht nachvollziehbaren Gründen deutlich langsamer mit 144 MB/s. Mein Verdacht liegt auf den unterschiedlichen Treibern durch die unterschiedlichen Controller. Die WD läuft mit dem alten 'USB' treiber, während die Seagate per default mit UASP bedient wird.
Dass Windows 10 da plötzlich schneller auf eine USB HDD schreibt als Windows 11 ist schon lustig finde ich. Ist nicht dramatisch, aber genug dass es in einem direkten Vergleichstest auffällt.
Die nächste Überraschung kam dann als ich NTFS testete. Der wahrscheinlichere Anwendungsfall für 20 TB HDD, wer benutzt denn da exFAT?
War nicht sicher ob ich die Werte normieren sollte für eine bessere Übersichtlichkeit. Hier hab ichs gemacht. Plötzlich war die Seagate deutlich langsamer und nicht die WD. Um die 144 MB/s bei der Seagate und um die 190 MB/s bei der WD. Sah aus als hätte ich einfach die Logs vertauscht, aber ich habe am ende 4 Durchläufe gemacht und das Script um die Ausgabe der Laufwerksbuchstaben ergänzt und wenn ich nicht gerade völlig blind bin ist das nur zufall dass der Wert der WD mit exFAT fast genau dem der Seagate mit NTFS entspricht.
An diesem Punkt wusste ich dass da etwas faul ist und entschloss mich unter Linux etwas ausgiebiger zu testen.
Anfangs noch etwas chaotisch, das benchmarkscript stück für stück verbessernd kamen dann die logs zusammen und irgendwann habe ich die in eine Tabelle überführt. Eine direktausgabe in csv wäre definitiv eine überlegung wert >.>
Ich habe keine Ahnung wie ich das sinnvoll visualisieren kann, daher eine (aus meiner sicht unübersichtliche) Übersicht der wichtigsten Tests:
und eine 'richtige' Übersicht mit Transferraten in einer Tabelle und farblicher Kennzeichnung als 'heatmap'
Wer sich hier erschlagen fühlt kann einfach hochscrollen und das 'tldr-fazit' lesen
Was ich da rauslese ist erstmal dass Win 11 in sachen I/O stellenweise sichtbar und ggf. sogar spürbar schlechter abschneidet als noch Win 10.
Außerdem ist Linux schneller auf NTFS unterwegs als Windows selbst. Damit hatte ich absolut nicht gerechnet, das war eher ein 'mal sehen wie schlimm es ist' test.
Die meisten Dateisysteme haben deutliche Probleme sobald es um viele kleine Dateien geht, doch interessanterweise scheint das nicht für Btrfs und XFS zu gelten. Sieht man mal über die schwache gesamtperformance von XFS hier hinweg ist sowohl das lesen, als auch das schreiben bei den Problemfällen (Endless Sky, M&B, SH3) nicht so schlecht wie bei NTFS, ext4 usw.
Allgemein war ich überrascht dass Btrfs hier aus meiner sicht recht deutlich den Gesamtsieg einfährt. Selbst ohne kompression spielt es ganz oben mit und schaltet man zstd in Stufe 3 - das dürfte auf allen modernen Desktop CPUs nahezu unmerklich sein was die CPU-last angeht - wird es teilweise sogar richtig schnell. Wo NTFS, exFAT und ext4 beim lesen auf 50-60 MB/s einbrechen liest Btrfs mit 180 MB/s und mehr.
ext4 war für mich persönlich die unerwartete Enttäuschung, allerdings lässt es sich mit einer Zusatzoption beim formatieren auf ein solides Niveau bringen. Allerdings muss man da eben auf dem Terminal per hand formatieren und mal einen Blick ins Handbuch werfen. Obwohl die Option als abhilfe für die SMR schwäche gedacht war profitiert auch die WD davon.
Die schwache Leseperformance unter ZFS hat mich auch überrascht. Genauso wie bei XFS beschleicht mich da das Gefühl dass sich das vermutlich durch eine angepasste konfiguration beheben lässt. Oder liegt es daran dass es ein externes Kernelmodul ist?
Ich kam leider erst beim zstd:10 test auf die idee mal mit ins log zu schreiben wie sich das nun komprimieren ließ
Nicht weltbewegend, aber genug für den manchmal garnicht so kleinen geschwindigkeitsboost.
Einmal habe ich dann auch noch mit bees dedupliziert, wie man sieht hält sich das ergebnis mit rund 4 gesparten GB ziemlich in grenzen. Kann man sich für diese Testdaten auch sparen.
Sieht eventuell anders aus wenn man mehrere Spieleinstallationen parallel hat für unterschiedliche Mods.
Genauso sind die Dateissysteme jedes mal frisch und die Daten werden vergleichsweise günstig geschrieben, wenn auch nicht zwingend optimal (NTFS fragmentiert auch gerne mal wenn man einen ordner in ein frisches Dateisystem schiebt). Der eigentliche Praxistest wäre für eine Backupplatte ein potentiell gut gefülltes Dateisystem mit einer längeren Geschichte an updates. Löschungen, ersetzungen/ergänzungen bestehnder Dateien in quasi-zufälliger Reihenfolge. Doch die Platten überhaupt erstmal halb voll zu schreiben nach dem formatieren wäre schon eine ziemliche Geduldsprobe, von einem simulierten altern und fragmentieren der Daten ganz zu schweigen. Möglicherweise ließe sich das abkürzen indem man auf einer 1-2 TB Partition testet. Da müsste man nur aufpassen dass die optionen bei der formatierung noch die gleichen sind.
Außerdem ist mir nicht klar ob die Seagate irgendeine Information darüber hat wo Daten liegen. Laut Systeminfo wird kein TRIM unterstützt und demnach sollte der controller auch nicht wissen was frei und was benutzt ist. Trotzdem lieferte ein kleiner Test der SMR sichtbar machen sollte kein Ergebnis. Vielleicht habe ich die Platte auch einfach noch nicht genug beschrieben.
Auch wenn es unsinnig scheint will ich noch schauen was rauskommt wenn ich beide Platten gespiegelt mit einem Btrfs betreibe. Ich rechne zwar damit dass eine manuelle synchronisation per send-receive das sinnvollere und sichere vorgehen ist, aber vielleicht lässt sich damit dann lesend der usb 3 anschluss ausreizen. Mit einer wahrscheinlich CMR-SMR RAID combo, das hätte schon was.
Ich hoffe dass das der eine oder andere interessant findet und lasst gerne feedback da.
Ein paar Infos ergänze ich noch wenn nicht gerade die Dämmerung naht.
Wie kommts?
Ich suchte eine Ablösung für die 3 8 TB Seagate Archive HDD im Homeserver/eigenbauNAS. Statt RAID-Z1 mit ZFS sollten zwei HDDs in einfacher Spiegelung laufen damit es etwas schneller geht wenn ich Backupdaten so (klein und zerstückelt) wie sie sind rüberschiebe. Ich nehme zumindest an dass SMR Platten mit 2+parität nicht besonders gut für die Schreibperformance sind wenn man z.b. seinen Benutzerordner sichern will.Die Festplattenpreise sind nun leider auch gestiegen, also habe ich zum ersten mal in den sauren Apfel der fertig-externen gebissen anstatt interne HDDs und Gehäuse extra zu kaufen. Der Preisunterschied war recht erheblich. Seagate zeigt auch warum das die schlechtere Option ist mit wahrscheinlich nicht ausgewiesenem SMR.
Ersteindruck
Amazon hat praktisch auf Polsterung verzichtet, nur an einer Seite gab es Knüllpapier. Oben, unten, rechts, links und 'hinten' lagen die inneren Kartons direkt am äußeren an und natürlich hatte dieser eine deutlich eingedrückte Ecke die eine etwas rauere Handhabung vermuten lässt. Da ist mir ein spezialisierter Hardwarehändler lieber, Mindfactory, Alternate usw hatten da meiner Erfahrung nach fast immer angepasste Verpackungen und mir ist die dicke, mehrschichtige Luftpolsterfolie mit Klebeband um die blanke HDD bei Mindfactory irgendwie lieber als z.b. der relativ steife Kunststoff der die einzige Stoßdämpfung für die WD darstellte.
Ich hatte da schon den Gedanken "Das hast du davon Festplatten bei Amazon zu bestellen."
Aber scheint alles ok zu sein, also ist das vielleicht auch übertriebene Sorge.
Zunächst einmal habe ich grundlegende Funktionstests gemacht und einen 'extended' Selftest per SMART laufen lassen. Das war nicht so einfach wie es hätte sein können, denn unter Linux funktioniert SMART nicht out of the box für die Seagate per smartctl und die WD betrachtet einen laufenden Selbsttest nicht als ausreichenden Grund nicht die Spindel anzuhalten und sich in den Tiefschlaf zu begeben.
Die Seagate brauchte einen wechsel vom 'uasp' treiber auf den älteren 'usb' treiber, dann gibts auch volle SMART funktionalität per smartctl. Vielleicht ginge das auch wenn man das von smartctl verwendete protokoll korrigiert, doch ich hatte nicht den Mut da durchzuprobieren bis etwas funktioniert. Am Ende bricke ich die Platte oder das Gehäuse. Erzwingt man den scsi modus gibt es immerhin die Identifikationsdaten auch mit 'uasp' treiber, was die Zuordnung beim ständigen neu formatieren deutlich entspannter macht.
Zu WD könnte man hier sagen dass alles wie erwartet funktioniert, jedoch gibt es die für mich nicht nachvollziehbare entscheidung im eigenen (Windows)tool die Elements Reihe von der SMART Erkennung auszuschließen, selbst wenn die Platte und das Gehäuse diese Möglichkeiten offensichtlich bieten.
Code:
smartctl 7.5 2025-04-30 r5714 [x86_64-linux-6.19.10-1-cachyos] (local build)
Copyright (C) 2002-25, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Vendor: Seagate
Product: Expansion HDD
Revision: 1802
Compliance: SPC-4
User Capacity: 20.000.588.955.136 bytes [20,0 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LU is fully provisioned
Logical Unit id: 0x3e54314834525435
Serial number: 00000000NT1H4RT5
Device type: disk
Local Time is: Sun Apr 5 01:25:08 2026 CEST
SMART support is: Unavailable - device lacks SMART capability.
=== START OF INFORMATION SECTION ===
Device Model: WDC WD200EDGZ-11CNKA0
Serial Number: SCH2TG7V
LU WWN Device Id: 5 000cca 425cf5c10
Firmware Version: 85.00A85
User Capacity: 20.000.588.955.648 bytes [20,0 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 7200 rpm
Form Factor: 3.5 inches
Device is: Not in smartctl database 7.5/5706
ATA Version is: ACS-5 (minor revision not indicated)
SATA Version is: SATA 3.5, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Sun Apr 5 01:30:37 2026 CEST
SMART support is: Available - device has SMART capability.
SMART support is: EnabledBeide Platten bieten eine eher unangenehme Geräuschkulisse, ein recht hohes summen und eine der beiden fiept offenbar oberhalb meines Hörbereichs. Das Gehäuse der Seagate setzt gelegentlich mit der HDD zum duett an wenn beide sich auf eine Resonanzfrequenz einigen. Ein berühren mit dem Finger genügt um das zu stoppen, was aus meiner Sicht deutlich macht dass das vermeidbar wäre.
Die WD dagegen hat ein stetiges klacken, bestehend aus zwei verschiedenen Klacklauten in unterschiedlichen Intervallen soweit ich das feststellen konnte. Ganz ohne Aktivität von außen wohlgemerkt. Vielleicht schreibt die ihr Temperaturlog für SMART alle 5 sekunden auf die Platter.
Kommentar eines Freundes der noch hohe Frequenzen hört war sinngemäß 'Die eine Festplatte gibt Tinnitus und die andere furzt.'
Für den vermeintlichen Anwendungsfall einer einfachen Speichererweiterung für den Schreibtisch finde ich das reichlich unglücklich.
Erste Benchmarks
CrystalDiskMark unter Win 11 mit NTFS und aktiviertem Schreibcache für die Platten - was keine rolle spielen sollte für den Benchmark. Auffällig ist schon mal der deutliche Unterschied beim zufälligen Lesen. Die schreibleistung sieht bei beiden so ähnlich aus dass man nicht auf die Idee kommt dass eine der Platten SMR haben könnte.
Ursprünglich hatte ich nur vor noch ein paar einfache kopiertests unter Windows 10 (alter PC), Win 11 und Linux zu machen bevor ich die beiden ihrer geplanten Verwendung zuführe. Doch die Ergebnisse waren so unerwartet und aus meiner Sicht eigenartig dass ich noch mehr gemacht habe.
Doch was nimmt man für einen möglichst realitätsnahen Test? Große Dateien wie Videos sind vergleichsweise uninteressant, die schreibt man ein mal und liest danach nur noch mit relativ niedrigen Anforderungen an die Geschwindigkeit. Doch für ein naives 'ich will ein Backup von dem und dem Ordner' bräuchte es etwas das gemischte Daten bietet und gleichzeitig groß genug ist um die Ergebnisse nicht zu sehr durch caches zu verfälschen. Der Spieleordner auf einer der SSDs im alten PC schien genau das zu sein was ich suchte. Rund 380 GB mit Unterordnern voller weniger, großer Dateien und solchen die zehntausende in überschaubarer Größe bieten.
Baldurs Gate 3, Duke Nukem Forever, ELEX, Endless Sky, Mechwarrior Online (etwas älterer patchstand), Mount & Blade Warband mit einigen Mods, Silent Hunter 3, Elder Scrolls Online (älterer patchstand) und ein zip des M&B Ordners in älterer Fassung als Backup für irgendetwas.
| BG 3 | Duke Nukem | ELEX | Endless Sky | MWO | M&B Warband | SH3 | ESO | M&B zip | |
| Größe in GiB | 144,68 | 8,18 | 26,5 | 0,92 | 29,3 | 24,59 | 2,49 | 134,21 | 14,44 |
| Dateien+Ordner | 342+26 | 1350+103 | 51+8 | 12457+323 | 294+61 | 52430+332 | 22538+412 | 650+48 | 1+0 |
Der Anfang war ein einfaches shellscript für robocopy das noch kurz genug ist um es kurz vorzustellen.
Code:
@REM Change the code page to UTF-8.
%SystemRoot%\System32\chcp.com 65001 >NUL
set drive=E
set robocopyoptions=/MIR /COPY:DAT /J /DST /R:0 /W:0 /TEE /NDL /NFL /UNILOG+:D:\hddbench\hddbench%drive%.log
wmic logicaldisk get caption, volumename > D:\hddbench\hddbench%drive%.log
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\Baldurs Gate 3" "%drive%:\benchtarget\Baldurs Gate 3" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\Duke Nukem Forever" "%drive%:\benchtarget\Duke Nukem Forever" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\ELEX" "%drive%:\benchtarget\ELEX" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\Endless Sky" "%drive%:\benchtarget\Endless Sky" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\MechWarrior Online" "%drive%:\benchtarget\MechWarrior Online" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\MountBlade Warband" "%drive%:\benchtarget\MountBlade Warband" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\Silent Hunter 3" "%drive%:\benchtarget\Silent Hunter 3" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget\Zenimax Online" "%drive%:\benchtarget\Zenimax Online" %robocopyoptions%
%SystemRoot%\System32\robocopy.exe "D:\hddbench\benchtarget" "%drive%:\benchtarget" "MountBlade Warband.zip" %robocopyoptions%
pauseDas (bash)script für Linux ist etwas größer und komplexer, das liegt für interessierte im Anhang. Das soll auch eher als Beispiel dienen und nicht als fertiges Script für eigene Benchmarks. Da sind keine Sicherungen, keine Fehlerbehandlung, ein aufruf eines subscripts das mit root rechten den cache leert bevor der lesetest beginnt und Aufrufe für Programme die evtl nicht jeder installiert hat drin. Vor allem aber keine Sicherungen gegen Fehler! Am Ende wird der als Argument übergebene Zielordner mittels 'rm -r' rekursiv gelöscht, wer da einen existierenden Ordner mit Inhalt angibt hat hoffentlich ein Backup.
Deep-dive
- jetzt könnte es etwas zu detailliert werden -
Beide Platten kamen mit exFAT und 128kB Clustergröße. Der Schreibcache war per default deaktiviert, ich nehme an das ist der standard von Windows für USB Datenträger.- jetzt könnte es etwas zu detailliert werden -
Als erstes habe ich unter Win 10 (da lagen die Testdaten auf einer 2 TB Samsung 870 Evo) getestet wie groß der Einfluss der Protokollierung von Robocopy ist. Erstmal nur mit der Seagate. 5675 Sekunden für alles mit Auflistung der kopierten Dateien (aber ohne Verzeichnisse) und 5447 Sekunden ohne jegliche Auflistung. Grund genug im weiteren Verlauf darauf zu verzichten, ich will ja schließlich nicht messen wie schnell die Textausgabe des Terminals ist.
Die mittlere Schreibrate war allerdings unterirdisch mit rund 69, bzw 72 MB/s. Das war unerwartet langsam. Doch da exFAT auch nur ein besseres FAT32 ist das ohne journaling wahrscheinlich brav sequentiell für jede Datei den Eintrag in der Dateitabelle macht und die Daten schreibt bedeutet das eben viel hin und her für den Schreib-lesekopf. Mit dem Schreibcache sah das schon besser aus mit 2244 Sekunden (rund 175 MB/s)
Soweit klar, wie schon Crystaldiskmark zeigte ist die Seagate etwas schneller. Die erste Überraschung zeigte sich als ich die Tests auf Win 11 wiederholte. Mit Schreibcache da exFAT ohne viel zu langsam ist als dass ich das ohne in betracht ziehen würde.
Doch während die Seagate da eine ähnliche Leistung ablieferte (172-174 MB/s) war die WD aus nicht nachvollziehbaren Gründen deutlich langsamer mit 144 MB/s. Mein Verdacht liegt auf den unterschiedlichen Treibern durch die unterschiedlichen Controller. Die WD läuft mit dem alten 'USB' treiber, während die Seagate per default mit UASP bedient wird.
Dass Windows 10 da plötzlich schneller auf eine USB HDD schreibt als Windows 11 ist schon lustig finde ich. Ist nicht dramatisch, aber genug dass es in einem direkten Vergleichstest auffällt.
Die nächste Überraschung kam dann als ich NTFS testete. Der wahrscheinlichere Anwendungsfall für 20 TB HDD, wer benutzt denn da exFAT?
War nicht sicher ob ich die Werte normieren sollte für eine bessere Übersichtlichkeit. Hier hab ichs gemacht. Plötzlich war die Seagate deutlich langsamer und nicht die WD. Um die 144 MB/s bei der Seagate und um die 190 MB/s bei der WD. Sah aus als hätte ich einfach die Logs vertauscht, aber ich habe am ende 4 Durchläufe gemacht und das Script um die Ausgabe der Laufwerksbuchstaben ergänzt und wenn ich nicht gerade völlig blind bin ist das nur zufall dass der Wert der WD mit exFAT fast genau dem der Seagate mit NTFS entspricht.
An diesem Punkt wusste ich dass da etwas faul ist und entschloss mich unter Linux etwas ausgiebiger zu testen.
Anfangs noch etwas chaotisch, das benchmarkscript stück für stück verbessernd kamen dann die logs zusammen und irgendwann habe ich die in eine Tabelle überführt. Eine direktausgabe in csv wäre definitiv eine überlegung wert >.>
Ich habe keine Ahnung wie ich das sinnvoll visualisieren kann, daher eine (aus meiner sicht unübersichtliche) Übersicht der wichtigsten Tests:
und eine 'richtige' Übersicht mit Transferraten in einer Tabelle und farblicher Kennzeichnung als 'heatmap'
Wer sich hier erschlagen fühlt kann einfach hochscrollen und das 'tldr-fazit' lesen
Was ich da rauslese ist erstmal dass Win 11 in sachen I/O stellenweise sichtbar und ggf. sogar spürbar schlechter abschneidet als noch Win 10.
Außerdem ist Linux schneller auf NTFS unterwegs als Windows selbst. Damit hatte ich absolut nicht gerechnet, das war eher ein 'mal sehen wie schlimm es ist' test.
Die meisten Dateisysteme haben deutliche Probleme sobald es um viele kleine Dateien geht, doch interessanterweise scheint das nicht für Btrfs und XFS zu gelten. Sieht man mal über die schwache gesamtperformance von XFS hier hinweg ist sowohl das lesen, als auch das schreiben bei den Problemfällen (Endless Sky, M&B, SH3) nicht so schlecht wie bei NTFS, ext4 usw.
Allgemein war ich überrascht dass Btrfs hier aus meiner sicht recht deutlich den Gesamtsieg einfährt. Selbst ohne kompression spielt es ganz oben mit und schaltet man zstd in Stufe 3 - das dürfte auf allen modernen Desktop CPUs nahezu unmerklich sein was die CPU-last angeht - wird es teilweise sogar richtig schnell. Wo NTFS, exFAT und ext4 beim lesen auf 50-60 MB/s einbrechen liest Btrfs mit 180 MB/s und mehr.
ext4 war für mich persönlich die unerwartete Enttäuschung, allerdings lässt es sich mit einer Zusatzoption beim formatieren auf ein solides Niveau bringen. Allerdings muss man da eben auf dem Terminal per hand formatieren und mal einen Blick ins Handbuch werfen. Obwohl die Option als abhilfe für die SMR schwäche gedacht war profitiert auch die WD davon.
Die schwache Leseperformance unter ZFS hat mich auch überrascht. Genauso wie bei XFS beschleicht mich da das Gefühl dass sich das vermutlich durch eine angepasste konfiguration beheben lässt. Oder liegt es daran dass es ein externes Kernelmodul ist?
Ich kam leider erst beim zstd:10 test auf die idee mal mit ins log zu schreiben wie sich das nun komprimieren ließ
Code:
compsize of target:
Processed 90113 files, 2149529 regular extents (2149529 refs), 6157 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 88% 341G 385G 385G
none 100% 177G 177G 177G
zstd 78% 163G 207G 207G
compsize after bees:
Processed 90113 files, 2064918 regular extents (2249145 refs), 6157 inline.
Type Perc Disk Usage Uncompressed Referenced
TOTAL 90% 337G 372G 380G
none 100% 177G 177G 177G
zstd 82% 160G 195G 202GEinmal habe ich dann auch noch mit bees dedupliziert, wie man sieht hält sich das ergebnis mit rund 4 gesparten GB ziemlich in grenzen. Kann man sich für diese Testdaten auch sparen.
Sieht eventuell anders aus wenn man mehrere Spieleinstallationen parallel hat für unterschiedliche Mods.
Offene Fragen (meinerseits)
Angesichts der Größe der Platten bin ich mir nicht so sicher ob die da nicht noch mit internem Cache arbeiten könnten. Es wäre durchaus vorstellbar dass auch die WD SMR benutzt, aber ein, zwei TB CMR zur Verfügung hat um Schreibzugriffe aufzufangen und in aller ruhe einzusortieren.Genauso sind die Dateissysteme jedes mal frisch und die Daten werden vergleichsweise günstig geschrieben, wenn auch nicht zwingend optimal (NTFS fragmentiert auch gerne mal wenn man einen ordner in ein frisches Dateisystem schiebt). Der eigentliche Praxistest wäre für eine Backupplatte ein potentiell gut gefülltes Dateisystem mit einer längeren Geschichte an updates. Löschungen, ersetzungen/ergänzungen bestehnder Dateien in quasi-zufälliger Reihenfolge. Doch die Platten überhaupt erstmal halb voll zu schreiben nach dem formatieren wäre schon eine ziemliche Geduldsprobe, von einem simulierten altern und fragmentieren der Daten ganz zu schweigen. Möglicherweise ließe sich das abkürzen indem man auf einer 1-2 TB Partition testet. Da müsste man nur aufpassen dass die optionen bei der formatierung noch die gleichen sind.
Außerdem ist mir nicht klar ob die Seagate irgendeine Information darüber hat wo Daten liegen. Laut Systeminfo wird kein TRIM unterstützt und demnach sollte der controller auch nicht wissen was frei und was benutzt ist. Trotzdem lieferte ein kleiner Test der SMR sichtbar machen sollte kein Ergebnis. Vielleicht habe ich die Platte auch einfach noch nicht genug beschrieben.
Auch wenn es unsinnig scheint will ich noch schauen was rauskommt wenn ich beide Platten gespiegelt mit einem Btrfs betreibe. Ich rechne zwar damit dass eine manuelle synchronisation per send-receive das sinnvollere und sichere vorgehen ist, aber vielleicht lässt sich damit dann lesend der usb 3 anschluss ausreizen. Mit einer wahrscheinlich CMR-SMR RAID combo, das hätte schon was.
Ich hoffe dass das der eine oder andere interessant findet und lasst gerne feedback da.
Ein paar Infos ergänze ich noch wenn nicht gerade die Dämmerung naht.
