Leserartikel 20 TB WD Elements und Seagate Expansion Desktop im Vergleich + Dateisystembenchmarks

[Bigeagle]

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.

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.

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: Enabled

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.

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. (Nachtrag: was offenbar auch nicht der Fall ist.)

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

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.

@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%
pause

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.

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.
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 (vermeintliche) 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ß

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         202G

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.

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.

Nachtrag 1 mit Details zu den Verwendeten Optionen der Dateisysteme und ein paar Graphen zum Test
Nachtrag 2 mit Test zur Klärung ob nun SMR auf der Seagate verwendet wird oder nicht mit negativem Ergebnis

 

[Purche]

Bei WD bekommen alle Whitelabel Platten eine Firmware der 5400er Klasse. Auch wenn die Platte hardwaretechnisch auf 7200 RPM basiert wie die teuren Gold, Ultrastar etc. (bzw. sogar mal eine solche werden sollten bis zur Ausmusterung). Also auch die 20 TB Platte hier aus dem Test, die ja die physikalischen 7200 RPM korrekt ausgibt.
Diese Firmware enthält eine Datendurchsatzdrossel, die die real mögliche Übertragungsgeschwindigkeit um ca. 30% auf Werte runterbremst, die für 5400er Platten typisch sind. Dieselbe Drossel läuft auch in der Firmware offizieller Red Plus Platten, sofern diese auf 7200er Hardware basieren. Also, da WD die Red Plus Reihe in der 5400er Leistungsklasse vermarktet, haben die halt langsamer zu sein als ggf. baugleiche Platten der Red Pro Reihe.

Zumindest bis vor 2, 3 Jahren gab es einen Bug, mit dem sich diese Drossel zeitweise deaktivieren ließ. Während ein extended SMART Test aktiv ist, wird bei solchen Platten die Drossel deaktiviert und plötzlich laufen parallele Datenübertragungen mit der vollen möglichen Übertragungsgeschwindigkeit. Könnte man hier auch noch mal ausprobieren, ob das noch geht.


Das Klicken alle 5 Sekunden kommt nicht vom Speichern irgendwelcher Logs sondern kommt durch die Preemptive Wear Leveling (PWL) Technologie. Da vollzieht der Arm alle ca. 5 Sekunden einen Schwenk um das Gleitmittel wieder gleichmäßig über die Platteroberfläche zu verteilen um Verschleiß zu minimieren. Bei manchen Platten ist das mehr hörbar, bei anderen weniger. Offenbar Serienstreuung...

WD hat (DM-)SMR Platten nur bis maximal 6 TB hergestellt. WD-Platten mit 8 TB aufwärts sind also bislang durchweg CMR. Meines Wissens wurde die Produktion von (DM-) SMR Platten in 3,5" bei WD inzwischen komplett eingestellt.

 

[Banned]

Die schreibleistung sieht bei beiden so ähnlich aus dass man nicht auf die Idee kommt dass eine der Platten SMR haben könnte.

SMR merkt man eigentlich erst, wenn etwa die Hälfte der Platte beschrieben ist. Vorher wird ganz normal geschrieben und halt eine Spur immer Platz gelassen. Erst, wenn das nicht mehr geht und umstrukturiert werden muss, wird es langsam.

Abgesehen davon gibt es aber bei Geizhals keine Festplatten in dieser Größe mit SMR:
https://geizhals.de/?cat=hde7s&xf=5744_>=20TB&pagesize=30&sort=p&promode=true&hloc=de

Also ist es wohl eher unwahrscheinlich, dass eine davon SMR nutzt.

 

[Rickmer]

Abgesehen davon gibt es aber bei Geizhals keine Festplatten in dieser Größe mit SMR

Das hatte mich auch gewundert, wobei die Liste definitiv unvollständig ist, weil es mindestens diverse enterprise SMR HDDs im 28-34 TB Bereich gibt.

Mindestens existiert die Seagate Exos X20z (ST20000NM001J), aber die ist host-managed SMR und scheint damit für ein externes Laufwerk eher ungeeignet weil man da einen custom Controller für bräuchte.

 

[Purche]

Mindestens existiert die Seagate Exos X20z (ST20000NM001J), aber die ist host-managed SMR und scheint damit für ein externes Laufwerk eher ungeeignet weil man da einen custom Controller für bräuchte.

Ja, HM-SMR Modelle gibt es viele, aber auf dem freien Markt kaum bestellbar.

Selbst mit speziellen USB-Controllern wäre es bei HM-SMR Platten nicht realistisch möglich, nur eine einzelne Datei rauf zu schreiben oder an einer bestehenden Datei eine Änderung vorzunehmen. Da immer nur eine ganze Zone auf einmal änderbar ist und die Platten keinen CMR Cachebereich haben um die Daten erstmal selbst zu sammeln bis genug da ist.

 

[Bigeagle]

Nachtrag 1:
Details zu den Dateisystemen

exFAT habe ich iirc nur mit 128k Clustern getestet. Ein Test mit wie z.b. von Windows vorgeschlagen 2M Clustern wäre vielleicht noch interessant. Tatsächlich muss man für die Werksformatierung unter windows auf diskpart zurückgreifen und manuell den Wert vorgeben. In der GUI lässt sich dieser nicht einmal auswählen. Auch führt diskpart unter Win11 exFAT nicht einmal als verfügbare option für das volume auf. Vielleicht verstehe ich aber auch den sinn des Befehls 'filesystems' nicht richtig.
mountingoptionen unter linux: (rw,nosuid,nodev,relatime,uid=1000,gid=1000,fmask=0022,dmask=0022,iocharset=utf8,errors=remount-ro,uhelper=udisks2)

NTFS hatte immer 8k Cluster, 4k wird nur bis etwa 16 TiB unterstützt. Damit ist leider auch keine Kompression mehr verfügbar.
mountingoptionen unter linux: (rw,nosuid,nodev,relatime,uid=1000,gid=1000,acl,iocharset=utf8,prealloc,uhelper=udisks2)
naiv manuell mounten per 'mount -o rw' hat nur zu read-only mounts geführt. einige der optionen da scheinen wohl nötig zu sein.

ext4 wurde zuerst mit 'mkfs.ext4 -b 4k -E lazy_itable_init=0,lazy_journal_init=0 -L SGExpansion /dev/sdc1' erstellt, danach als 'packedmeta' test mit 'mkfs.ext4 -b 4k -E lazy_itable_init=0,lazy_journal_init=0,packed_meta_blocks=1 -O flex_bg -L SGExpansion /dev/sdc1'
die 'lazy_init' optionen erzwingen die sofortige erstellung der inodes, ansonsten würden diese beim ersten einhängen im leerlauf angelegt werden was die benchmarkergebnisse vermutlich verfälschen würde.
mountingoptionen unter linux für den packedmeta test: (rw,nosuid,nodev,relatime,errors=remount-ro,uhelper=udisks2)
die älteren sind noch nicht im log gelandet, sollten aber dem zusatz im testnamen entsprechen

XFS wurde mittels 'mkfs.xfs -f -L SGExpansion /dev/sdc1' erstellt, da die defaults sinnvoll erschienen, wie z.b. 4k blocks anstatt 512 Byte.
moutingoptionen: (rw,nosuid,nodev,relatime,inode64,logbufs=8,logbsize=32k,noquota,uhelper=udisks2)

Btrfs wurde mittels 'mkfs.btrfs -f -L WDElements /dev/sdb1' erstellt.
Mountinoptionen je nach Test
simple: (rw,nosuid,nodev,relatime,space_cache=v2,subvolid=5,subvol=/)
zstd:3: (rw,nosuid,nodev,relatime,compress-force=zstd:3,space_cache=v2,subvolid=5,subvol=/)
und entsprechend angepasst für zstd:10 und 15

ZFS wurde mittels 'zpool create -f -o ashift=12 -m /media/zfssg sgpool e4a6b425-d237-4ccf-bb7a-5a7f788ef0d3' erzeugt
moutingoptionen sind leider keine im log gelandet
die kompression wurde dann für den zstd:3 test mittels 'zfs set "compression=zstd-3" sgpool' geändert, sonst gab es keine anpassungen

Mir fiel irgendwann ein dass die 'defaults' eventuell unterschiedlich sind je nach Linux Distro, erst da habe ich dann die mountingoptionen mit ins log schreiben lassen.
Ein test wie viel einfluss ein 'noatime' hätte soll irgendwann noch folgen.

Im Anhang noch zwei Bilder mit dem output von 'sadf', damit lassen sich unkompliziert svgs aus den mitgeloggten daten der systemüberwachung mit 'sar' erzeugen. Nicht unbedingt die hübschesten, aber ich vermute die funktion ist mehr für eine schnelle übersicht gedacht. Ich hätte ja gern die Breite der Graphen angepasst damit man evtl mehr Details sieht, aber entweder ist die Option gut versteckt, oder da muss man die Daten anders in einen Graph überführen.
Interessant fand ich dass die WD mit bis zu 1 MiB io requests arbeitet, die Seagate dagegen nur bis 512 kiB. Auch sieht man bei ext4 gut die Unterschiede bei den beiden Platten. Bei Btrfs wirkt der gleiche kopiervorgang dagegen wie glattgebügelt.
Ich habe die Graphen einfach nur nebeneinanderge'klebt', ansonsten sind die so wie sie sadf ausspuckt und in png umgewandelt.

Zur Erläuterung:
ganz oben die 'transfers per second' - tps. Die Anzahl an Befehlen die an das Gerät gesendet wurden.
Darunter die Transferraten in 'wkB/s' fürs schreiben, 'rkB/s' fürs lesen und hier ungenutzt 'dkB/s' für discard was für TRIM Befehle genutzt würde.
areq-sz ist die mittlere größe der Transfers (gemittelt über welchen zeitraum steht nicht an der gleichen stelle in manual) und aqu-sz ist die mittlere Länge der Warteschlange.
await ist die Latenz für die Transfers in ms und beinhaltet die dauer in der Warteschlange sowie die eigentliche Ausführungsdauer.
ganz unten ist der Auslastungsgraph mit '%util' und hier vermutlich uninteressant.

Weiß zufällig jemand ob die Entscheidung bezüglich größe der Transfers und Länge der Warteschlange vom Treiber oder vom Gerät getroffen wird? Ggf. noch genauer ob das an der HDD direkt, oder am USB Controller des Gehäuses hängt?

P.S.: lade ich die pngs nur als anhang hoch kommt etwas kaputtes mit knapp 100kB raus, ziehe ich die direkt in den text funktioniert es. Bug im Forum, oder im Browser?
--- --- ---

Das Klicken alle 5 Sekunden kommt nicht vom Speichern irgendwelcher Logs sondern kommt durch die Preemptive Wear Leveling (PWL) Technologie. Da vollzieht der Arm alle ca. 5 Sekunden einen Schwenk um das Gleitmittel wieder gleichmäßig über die Platteroberfläche zu verteilen um Verschleiß zu minimieren.

Da stellt sich mir doch die Frage ob das wirklich alle 5 Sekunden sein muss und nicht ein größeres Intervall auch gereicht hätte.

Ansonsten scheint es als sei die SMR Sache doch nicht so naheliegend zu sein. Hat vielleicht jemand eine Idee wie sich das Testen lässt dass es potentiell mehrere Tage dauert?
So intuitiv würde ich vermuten dass ich z.b. kein CoW Dateisystem dafür nehmen sollte. Dann einmal mit z.b. 927 MiB dateien vollschreiben und die danach mit 925 MiB überschreiben um sicherzustellen dass man nicht zufällig die interne Zonengröße trifft.
Oder das Dateisystem weglassen, die Platte einmal beliebig vollschreiben und anschließend synchron in kleinen blöcken überschreiben. Da müsste der HDD Controller bei SMR ja für jeden Block die ganze Zone neu schreiben und man muss sich nicht um Dateisystemeigenheiten oder aufteilung von einzeldateien in ordnern gedanken machen.

 

[JumpingCat]

Ansonsten scheint es als sei die SMR Sache doch nicht so naheliegend zu sein. Hat vielleicht jemand eine Idee wie sich das Testen lässt dass es potentiell mehrere Tage dauert?

Naja, du musst halt die Platten zwingen von "normal" auf "smr betrieb" zu switchen. Du kennst aber die interne cmr Zonen Größe für Caching nicht. Und die wird im Idle auch wieder geleert um die nach smr zu übertragen. Das merkst du aber schnell weil die Datenrate dann massiv einbricht. Diesen reddit Thread kennst du? Da sind einige Graphen dran: https://www.reddit.com/r/DataHoarder/comments/vc28fz/smr_worse_than_you_thought_very_slow_reads_too/

 

[it_green]

@JumpingCat Also muss man die Platten erstmal so richtig rannehmen damit sie in den SMR-Modus schalten, aber ohne die internen Details von den Herstellern ist das schwer zu testen. Wie will man denn da die richtigen Parameter finden, ohne einfach nur zu raten?

 

[Purche]

Also muss man die Platten erstmal so richtig rannehmen damit sie in den SMR-Modus schalten,

Naja, die Platte hat ggf. im Test schon lange auf SMR-Befüllung umgeschaltet, ohne dass du das feststellst. Wenn am Anfang die Platte leer ist, geht das erstmalige Vollschreiben der SMR-Bereiche (z.B. aus dem CMR Cache) super schnell. Denn in den Zielbereichen liegen schließlich noch keine aufzuhebenden Daten, die umgeschichtet werden müssten.

Die Bremse greift ja erst so richtig, wenn es nur noch wenig jungfräuliche SMR-Bereiche gibt, die also noch komplett frei sind. Oder wenn Daten, die bereits zuvor geschrieben wurden, plötzlich lokal geändert werden sollen und daher die ganzen Schindeln erst wieder eingelesen, geändert und neu geschichtet weg geschrieben werden müssen. Im Zweifelsfall kostet 1 Byte ändern dann die Zeit um 256 MB (also eine Viertelmilliarde so viel) einmal in den RAM des HDD Controllers zu lesen und nach minimaler Änderung wieder neu geschichtet auf den Platter zu schreiben.

Deswegen melden DM-SMR Platten dem Betriebssystem in der Regel auch TRIM Support. Damit die SMR-Steuerung auch mit bekommt in welchen zuvor geschrieben Sektoren Daten lagen, die mittlerweile wieder vom Betriebs- bzw. Dateisystem als gelöscht angesehen werden. Die Platte selbst hat ja von Dateisystemen keine Ahnung.

Da diese Platten aber ziemlich sicher kein DM-SMR nutzen, ist dieser Exkurs hier eh eher theoretisch.

 

[Banned]

Also muss man die Platten erstmal so richtig rannehmen damit sie in den SMR-Modus schalten, aber ohne die internen Details von den Herstellern ist das schwer zu testen.

Es ist nicht schwer zu testen. Wie gesagt, ab etwa der Hälfte der genutzten Kapazität schaltet die Festplatte unweigerlich in SMR-Betrieb - einfach weil sie nicht mehr im Pseudo-CMR-Modus weiterschreiben kann.

Also erzeuge dir eine 12TB-Datei und kopiere sie auf die Platte. Gegen Ende des Transfers wird SMR einsetzen.

PS: Wobei ich mich ganz ausdrücklich gegen so einen Test und den damit verbundenen relativ sinnlosen Energieverbrauch (außer du hast ein Balkonkraftwerk oder so) aussprechen möchte.

 

[Bigeagle]

@Banned das probier ich nun mal, mir fehlt sowieso noch eine doku mit schreibgeschwindigkeit über die ganze platte
zum energieverbrauch: da fallen die zwei platten kaum ins gewicht. Die dürften doch so jeweils 5-10 W nehmen. Der PC läuft sowieso und mit BOINC liegt der bei rund 280 W. Da spare ich eher woanders.
Aber ich würde schon gern wissen ob die nun SMR hat oder ob die auch ohne sowas derart unterschiedliche Charakteristiken haben. Am liebsten würde ich die ja noch ausbauen und direkt am SATA controller testen, am ende ist der USB auf SATA controller schuld. Leider haben die Gehäuse keine schrauben und ich habe ein gewisses Talent zum abbrechen von Kunststoffnasen in solchen Klemmgehäusen.

 

[Bigeagle]

Also SMR lässt sich wohl ausschließen. Einmal gut 16 TB am Stück schreiben ergab keine auffälligkeiten abgesehen von etwas größeren Schwankungen der Schreibrate auf der Seagate als auf der WD. Danach die Datei auf 15 TB gekürzt und mit fio eine 1 TiB mit 'randomwrite' in 10 MB Blöcken beschrieben bis 1 oder 4? TiB durch waren. Bin nicht mehr sicher. Hier zeigt die Seagate sehr viel größere Schwankungen, aber im Mittel ist sie nur geringfügig langsamer als die WD. Bei SMR hätte sie ja eigentlich irgendwann hart einbrechen müssen.
Danach der vollständigkeit halber noch einen kurzen 15 Minuten Test mit 4k Blöcken auf die 1 TiB Testdatei gemacht.
Verwendete Befehlszeile (für den 4k Test) ist nur leicht angepasst von stackexchange übernommen:
fio --name TEST --eta-newline=10s -eta=always --filename=fio-tempfile.dat --rw=randwrite --size=1Ti --io_size=4Ti --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=15m --group_reporting

	10 MB randomwrite	4k randomwrite
WD	129 MiB/s	2058KiB/s
Seagate	119 MiB/s	1640KiB/s

Die Unterschiede sind eher im Verlauf zu sehen, wo die WD schön gleichmäßig aussieht

Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:38m:52s]
Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:44m:16s]
Jobs: 1 (f=1): [w(1)][0.1%][w=130MiB/s][w=13 IOPS][eta 01h:49m:08s]
Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:51m:27s]
Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:53m:09s]
Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:54m:27s]
Jobs: 1 (f=1): [w(1)][0.1%][w=130MiB/s][w=13 IOPS][eta 01h:56m:21s]
Jobs: 1 (f=1): [w(1)][0.1%][w=140MiB/s][w=14 IOPS][eta 01h:57m:07s]
Jobs: 1 (f=1): [w(1)][0.2%][w=140MiB/s][w=14 IOPS][eta 01h:57m:45s]
Jobs: 1 (f=1): [w(1)][0.2%][w=140MiB/s][w=14 IOPS][eta 01h:58m:16s]
Jobs: 1 (f=1): [w(1)][0.2%][w=140MiB/s][w=14 IOPS][eta 01h:58m:43s]

Findet sich bei der Seagate sowas

Jobs: 1 (f=1): [w(1)][0.0%][w=140MiB/s][w=14 IOPS][eta 01h:42m:45s]
Jobs: 1 (f=1): [w(1)][0.1%][w=130MiB/s][w=13 IOPS][eta 01h:49m:09s]
Jobs: 1 (f=1): [w(1)][0.1%][w=120MiB/s][w=12 IOPS][eta 01h:54m:53s]
Jobs: 1 (f=1): [w(1)][0.1%][w=30.0MiB/s][w=3 IOPS][eta 02h:12m:37s]
Jobs: 1 (f=1): [w(1)][0.1%][w=30.0MiB/s][w=3 IOPS][eta 02h:29m:04s]
Jobs: 1 (f=1): [w(1)][0.1%][w=200MiB/s][w=20 IOPS][eta 02h:16m:56s]
Jobs: 1 (f=1): [w(1)][0.1%][w=200MiB/s][w=20 IOPS][eta 02h:08m:46s]
Jobs: 1 (f=1): [w(1)][0.1%][w=130MiB/s][w=13 IOPS][eta 02h:09m:17s]
Jobs: 1 (f=1): [w(1)][0.1%][w=50.0MiB/s][w=5 IOPS][eta 02h:17m:07s]
Jobs: 1 (f=1): [w(1)][0.1%][w=20.0MiB/s][w=2 IOPS][eta 02h:27m:29s]
Jobs: 1 (f=1): [w(1)][0.2%][w=200MiB/s][w=20 IOPS][eta 02h:20m:01s]

und im leider etwas grobem Graph sieht alles zusammen dann so aus
sdc links ist die WD, sdb rechts die Seagate

 

[Purche]

Möglicherweise handelt es sich bei der 20 TB Seagate Platte um eine 30TB Hardware auf HAMR-Basis, die per Firmware in der Kapazität reduziert wurde.

Zumindest war im letzten Jahr zu beobachten, dass der Ausschuss aus der Serie über diverse Produktsparten in den Markt gedrückt wurde, von Factory Recertified (selbst bei Modellen wie Exos 28 TB, die es zuvor noch nicht mal als Neuware am Markt gab), über externe Platten (wie evtl. hier) bis hin zu A-Ware Barracudas (teils runter bis 16 TB).

Vielleicht könnte HAMR solche Effekte erklären (wg Laser abkühlen lassen etc.), dazu kenne ich aber keine Details, also geraten.

Bei einer externen Platte kenne ich keinen Weg das von außen festzustellen bzw. auszulesen ob die HAMR nutzt, jedenfalls nicht ohne das Gehäuse zu öffnen. Auf der Platte wird bzw. muss unten links ein Laser Disclaimer aufgedruckt sein. Also falls du eh vorhaben solltest, sie auszubauen kannst du ja mal nachschauen.

 

[klampf]

Ich bin ein bisschen verwundert wieviel "Veschwörungstheorien" hier so unterwegs sind.
Denke alle in den extrenen Gehäusen ist nur Restmüll?

Ich vor kurzem eine 24TB Segate Expansion gekauft und da zigt CrystalDiskInfo auch die Bezeichnung an, wundert mich warum das hier bei der nicht geht.
Bei mir meldet die sich als Klassische Desktop HD, also genauso wie eine Std Barracuda.
Ich bin auch gar nicht auf die Idee gekommen, dass da was SMR sein könnte eben weil Geizhals keine mehr List in der Größe.
Ich habe einige von den Seagate 5 TB 2,5" SMR im Einsatz, daher hab ich auch ne Idee wie sich sowas benimmt.