WD60EFAX: Wenn Benchmarks bei SMR-Platten versagen

[mgutt]

Bei Hardwareluxx gibt es einen Test zur WD60EFAX, der teilweise so unrealistische Ergebnisse zeigte, dass sie diese nicht im Vergleich berücksichtigt haben. Die Redaktion bat sogar WD um eine Erklärung, aber die zeigten sich wenig kooperativ:

Western Digital verweigert dazu auch auf Anfrage jede Stellungnahme.

Nach einer umfangreichen Diskussion mit @Holt wie SMR eigentlich funktioniert, habe - zumindest ich ^^ - einiges darüber gelernt und wir hatten noch ein paar offene Theorien, die ich auf die Probe stellen wollte, weshalb ich mir die WD60EFAX einfach mal gekauft habe.

Dabei habe ich dann natürlich auch gleich mal die spannenden Ergebnisse von Hardwareluxx überprüft, so dass wir auch ohne Western Digitals Hilfe hinter die Lösung kommen. Wir beginnen mit einer einfachen Aufgabe. Laut HD Tune Pro soll die WD60EFAX mal eben im Mittel 378MB/s im Lese-Benchmark schaffen. Vielleicht steckt ja in Wirklichkeit eine SSD in dem Gehäuse ^^

Doch wie @Holt schon richtig vermutete, antwortet die WD60EFAX einfach mit "Null", wenn der Sektor noch nicht beschrieben wurde. Warum auch immer, tut sie das nicht, wenn keine Partition auf der Festplatte ist. Denn als ich in meinem Test diese entfernte, kam das dabei heraus:

Das sieht natürlich schon ganz anders aus. Trotzdem fallen extreme Spitzen auf und der Burst-Test sieht auch alles andere als "natürlich" aus (vorne ein dicker Streifen und "treppenartig" nach oben). Schauen wir uns zum Vergleich das Ergebnis des Vorgängers, der WD60EFRX (CMR) an:

Das Bild wirkt doch gleich ganz anders. Also habe ich die WD60EFAX komplett vollgeschrieben:

und den Test wiederholt:

Nun übersteigt die Platte plötzlich nicht mehr die 200 MB/s und liegt über den gesamten Speicherbereich 10 bis 20 MB/s unter dem ersten Benchmark.

Dann gab es aber noch was, was ich erst nicht verstanden habe. Und zwar der extrem gute 4K Random Write (für eine HDD) Wert in CrystalDiskMark (CDM):

Selbst eine IronWolf stinkt dagegen ab (hier übrigens mein Lesertest dazu):

So unwahrscheinlich das evtl erscheint, aber die WD60EFAX ist tatsächlich so schnell. Um das zu verstehen, muss man erst mal die SMR Speichertechnik verstehen. Bekanntlich werden hier Daten überlappend auf die Festplatte geschrieben:

Quelle: https://akiba-pc.watch.impress.co.jp/docs/sp/680650.html

Warum überlappend? Weil der Schreibkopf größer ist als der Lesekopf. Der Lesekopf kann problemlos den dünneren Streifen mit den Daten lesen, aber wenn geschrieben werden muss, benötigt der Schreibkopf mehr Platz. Vom Prinzip ist SRM also eine clevere Lösung um mehr Daten auf die Festplatte zu bekommen.

Allerdings haben wir nun das Problem, dass die Daten auf "Track N+2" mittendrin liegen und wenn diese nun verändert werden sollen, müsste man erstmal darüber liegenden Spuren "Track N+5" bis "Track N+3" jeweils einzeln auslesen und zwischenspeichern, bis man bei "Track N+2" loslegen kann.

Schon beim Lesen der Erklärung fällt denke ich auf, dass das nicht besonders schnell sein kann, wenn man ständig Spuren wechseln muss, also hat man sich den Media Cache ausgedacht:
https://www.computerbase.de/2014-12/10-terabyte-hdd-von-seagate-kommt-2015/

Wenn nun Daten verändert werden, werden diese nicht auf "Track N+2" geschrieben, sondern auf die Media Cache Spur, die eine klassische CMR Spur darstellt (siehe erstes Bild "Conventional Writes"). Und was nun richtig toll ist, dass man zufällige Dateiänderungen wie bei 4K Writes einfach sequentiell und nicht zufällig auf den Media Cache schreiben kann. In Wirklichkeit ist der 4K Write Benchmark von CDM (und allen anderen Benchmark-Tools) also kein 4K Write Benchmark, sondern ein Sequential Write Benchmark!

Das können wir sogar testen. Wir können zB mit HD Tune Pro den Write Benchmark mit 1MB Blockgröße durchführen lassen und ermitteln so über die gesamte Festplatte eine durchschnittliche Schreibgeschwindigkeit von 141 MB/s:

Nun machen wir einen Random-Write mit ebenfalls 1MB und voilà, mit durchschnittlich 151 MB/s ein sehr ähnlicher Wert (da nun auf CMR Spuren geschrieben wird, nicht absolut identisch):

Übrigens haben wir damit quasi auch schon bewiesen, dass der Media Cache nicht einfach am Anfang der Festplatte liegt, sondern es mehrere davon gibt, die jeweils in der Nähe der SMR Spuren liegen, denn sonst würde der Wert bei ca 200MB/s liegen. Das macht aber auch Sinn, denn sonst würde das Media Cache Cleaning, also das schlussendliche Schreiben der Datenänderungen auf die SMR Spur viel zu lange dauern.

Dieses Cache Cleaning passiert immer dann, wenn sich die WD60EFAX im Leerlauf befindet. Das Cleaning ist zwingend notwendig, denn sonst würde nicht nur irgendwann der Cache voll laufen, sondern beim sequentiellen Lesen geänderter Dateien, müsste die Festplatte ja ständig zwischen Media Cache Spur und SMR Spur wechseln.

Doch warum sehen wir das nicht beim sequentiellen Benchmark? Nun, CDM erstellt auf der Festplatte eine Benchmark-Datei, und startet den Lesetest immer vor dem Schreibtest. Wenn dann am Ende die Datei wieder gelöscht wird, werden auch die 4K Writes aus dem Media Cache gelöscht. Den 4K Write vor dem Lesetest auszuführen, lässt sich leider nicht einstellen. Außer wir tricksen 😇

Was habe ich nun gemacht? Ich habe CDM gestartet und nachdem die 4K Writes erledigt waren, habe ich den Prozess über den Ressourcen-Monitor abgeschossen, so dass die Benchmark-Datei erhalten blieb. Dann habe ich CDM neu gestartet und nach dem 1. Test habe ich das Programm über den Ressourcen-Monitor angehalten und einfach die alte Benchmark-Datei in die neue unbenannt. Nun war CDM gezwungen die alte Datei sequentiell einzulesen und sprang dabei fröhlich zwischen Media Cache und SMR Spur hin und her, was eine katastrophale Leistungseinbuße von fast 90% zur Folge hatte. Natürlich habe ich diesen Test auch mit der WD60EFRX durchgeführt und dort war wie zu erwarten keinerlei Leistungseinbruch festzustellen.

Wir wissen nun also auch, dass eine Leerlaufphase nach jeder Dateiänderung absolut notwendig ist. Und Leerlauf bedeutet, dass der Lese- und Schreibkopf nicht genutzt wird. Sofern man also die Festplatte in einem NAS betreibt und 2 Stunden lang einen Film schaut, so kann die Festplatte in der Zeit kein Cache Cleaning betreiben. Genauso wenig, wenn man sein NAS nach einer erledigten Aufgabe wie einem Backup schlafen schickt, weil man aus Energiespargründen den Weg über WoL bevorzugt und natürlich gilt das auch, wenn das Betriebssystem die Festplatte nach einer bestimmten Zeit schlafen schickt.

Doch wie lange dauert eigentlich das Cache Cleaning? Wie gesagt erstellt CDM immer erst eine Benchmark-Datei auf der Festplatte. Also habe ich erneut diese Datei erstellen lassen, die 4K Writes abgewartet und die Anwendung abgeschossen. Wir haben nun also eine gültige Datei auf der Festplatte, deren 4K Writes im Media Cache liegen. Das Cache Cleaning startet sofort, nachdem CDM aufgehört hat auf die Festplatte zuzugreifen (kann man hören). Ich habe also die Zeit gestoppt bis die Geräusche vorbei waren bzw ich habe einfach den Stromverbrauch überwacht, der während dem Cache Cleaning erhöht ist:

Es brauchte also etwas über 1,5 Minuten die Änderungen auf die SMR Spur zu schreiben. Allerdings sollte man sich nicht von der 1GiB großen Benchmark-Datei täuschen lassen. CDM ändert während dem 4K Write ja nur ca 6 Sekunden lang zufällige 4KB Blöcke der Datei. Es werden in Summe also vermutlich nur wenige MB (!) durch das Cache Cleaning auf die richtigen Positionen geschrieben.

Und selbst dabei darf man jetzt auch nicht vergessen, dass wir den Test mit einer komplett leeren Platte durchführen. Wenn die Benchmark-Datei auf einer Schindel läge, die von anderen Schindeln (Dateien) verdeckt würden. Das wäre ja gemein. Das wäre ja richtig fies, wenn man das auch zeigen würde ^^

... mehr dazu morgen.... jetzt geht es erstmal ins Bettchen

Update 10.06.

Gestern Abend habe ich eine 1GiB große Benchmark-Dateien auf der Platte hinterlassen und danach 1TB an Dateien auf die WD60EFAX kopiert. Damit wollte ich sicher gehen, dass die Schindeln mit den Benchmark-Dateien von den 1TB verdeckt werden. Ich habe dann das Spiel von gestern wiederholt. CDM eingefroren, alte Datei verwenden lassen, 4K Writes abgewartet und abgeschossen. Dann CDM erneut gestartet, eingefroren, alte Datei verwenden lassen und das war das Ergebnis:

Aua. Doch warum ist das eigentlich noch langsamer geworden? Lassen wir das doch mit den 4K Writes mal sein:

Interessant. Können von anderen Schindeln verdeckte Dateien etwa langsamer gelesen werden? Nein, denn jetzt wird es interessant. Die erste große Datei von den gestern kopierten 1TB kann ich mit 200 MB/s kopieren:

Eine in der Mitte mit 180 MB/s:

Und die letzte mit 160 MB/s:

Wir wissen also, dass die zuletzt kopierten Dateien weiter innen auf dem Platter liegen und daher langsamer kopiert werden. Und genau da liegt jetzt auch unsere Benchmark-Datei. @Holt wird es sicher bestreiten, aber damit bin ich mir sicher, dass wenn das Cache Cleaning läuft, dass dann die Daten nicht in die ursprüngliche SMR Zone kommen, sondern in die nächste freie und erst danach folgt ein TRIM/Garbage Collection um die Zone am Anfang für neue Dateien frei zu machen. Diese Funktion wird von WD LBA indirection genannt, wobei @Holt das nur auf den Media Cache und nicht allgemein auf die SMR Zonen bezieht.

Allerdings kann ich das denke ich noch anders aufzeigen, dass LBA Indirection auch die SMR Zonen betrifft. Denn bevor ich den zuvor genannten Test gemacht habe, hatte ich heute morgen als alle erstes ein Benchmark gestartet und wunderte mich über extrem gute Werte. Über 200 MB/s machen ja keinen Sinn, wenn bereits 1TB an Daten auf der Platte sind:

Ich wiederholte den Test mehrfach mit dem immer selben Ergebnis. Da ich bereits vermutete, dass wir nun eine freie Spur irgendwo am Anfang der Platte haben, startete ich CDM erneut und beendete den Prozess nach dem 1. Lesetest um die 1 GiB Datei auf der Platte zu behalten. Jeder folgende Benchmark fiel auf 185 MB/s:

Warum dieser Wert allerdings nicht auf 160 MB/s fällt, kann ich nicht erklären. Was aber denke ich klar ist, dass die Benchmark-Datei ihre Position auf den Plattern gewechselt hat, obwohl ich sie nur umbenannt habe und CDM Teile dieser Datei verändert hat. Sie wurde also nicht neu erstellt. Und es gab wie gesagt dadurch eine freie Spur ganz am Anfang der Platte, die jetzt nicht mehr da ist.

Weitere denkbare Tests:

• wie viele 4K Writes braucht es um den Media Cache voll laufen zu lassen und was für Auswirkungen hat das auf die Performance?
• erfolgt sofort eine Garbage Collection wenn Dateien auf unten liegenden Schindeln gelöscht werden oder landen neue Dateien erstmal im Media Cache und werden dann später dorthin platziert?

 

[C4rp3di3m]

Hmm sehr interessant. Um Ehrlich zu sein fand ich SMR schon immer dubios. Für mein Filmarchive im JBOD 4 Bay sind die ok, dort werden zu 90% nur einmal Sachen abgespeichert. Für alles andere Taugen diese Dinger nix.

Das es im Endeffekt nur noch 2 Hersteller gibt für HDDs Weltweit, sind wir Konsumenten diesem Cartel ausgeliefert. Mal ein Wasserschaden im Werk, mal SMR verhökern, hauptsache WD und SGT stopfen sich fein die Taschen voll. Habe gehört es gäbe 2TB SMR Platten was das, mit 1 Platter dann? Hersteller spart schön an Plattern joa ohne was an den Kunden weiterzugeben und dazu noch Betrügen.

Bleibt nur zu hoffen das die SMR wenigstens Haltbar sind, sonst bin ich mit meinem Archiv angeschissen, weil ich eine SMR 5TB und 6TB (Vermutlich auch SMR) in der Box habe, dazu eine 4TB und eine 2TB CMR. Schaun wa mal...

Deine Ankündigung reicht mir schon, morgen Zeigst du uns eine WD DATASETTE*

*1987 hatte ich das war damals schon Grausam, 1989 bekam ich mein erstes 1541 (das Fette). 1991 den A500 ... hach ja... ich fühl mich gerade Alt


mfg

 

[TorenAltair]

@mgutt Super Bericht, Hut ab!
Eine kleine Winzigkeit: beim Energieverbrauch im letzten Schaubild steht auf der y-Achse Volt. Das sollte Watt heissen?

 

[Holt]

antwortet die WD60EFAX einfach mit "Null", wenn der Sektor noch nicht beschrieben wurde. Warum auch immer, tut sie das nicht, wenn keine Partition auf der Festplatte ist. Denn als ich in meinem Test diese entfernte

Wie hast Du die Partition genau entfernt? Hast Du sie einfach in der Datenträgerverwaltung gelöscht oder mit DISPART und CLEAN oder gar CLEAN ALL? Wenn alleine das Vorhandensein der Partition so einen Unterschied macht, deutet dies darauf das der Controller der Platte die GPT Partitionstabelle auswertet und dies wäre extrem ungewöhnlich, weil eigentlich gar nicht nötig und da fragt sich dann wieso dies gemacht wird und eigentlich geht es den Controller gar nichts an was auf der Platte steht, sie könnte ja auch verschlüsselt sein oder Teil eines RAID 0, 5 oder 6 und dann funktioniert so eine Auswertung sowieso nicht mehr.

Und zwar der extrem gute 4K Random Write (für eine HDD) Wert in CrystalDiskMark (CDM):
...
Um das zu verstehen, muss man erst mal die SMR Speichertechnik verstehen.

Die Werte kommen alleine vom Media Cache, der ist bei den Device Managed SMR Platten zwar üblicherweise oder sogar immer zu finden, aber auch eine CMR HDDs kann so einen Media Cache haben und tatsächlich wurde er von HGST damals für Enterprise Nearline HDDs mit CMR erstmal vorgestellt / eingesetzt.

So hohe 4k Schreibend (zumindest solange man über einen deutlich Adressraum als den DRAM Cache der Platte bencht, stellt man auf 16MiB runter schafft man solche Werte bestimmt auch alleine über den DRAM Cache) und vor allem deutlich höhere Schreibend als lesend sind daher ein Hinweis auf einen Media Cache und der ist ein Hinweis aber SMR, aber noch kein schlüssiger Beweis dafür.

Allerdings sollte man sich nicht von der 1GiB großen Benchmark-Datei täuschen lassen. CDM ändert während dem 4K Write ja nur ca 6 Sekunden lang zufällige 4KB Blöcke der Datei. Es werden in Summe also vermutlich nur wenige MB (!) durch das Cache Cleaning auf die richtigen Positionen geschrieben.

Wobei man nicht vergessen sollte, dass diese HDD ja auch TRIM unterstützt und CDM die Testdateien am Ende löscht, womit Windows eigentlich die LBAs trimmen sollte die sie vorher belegt hatten und wenn TRIM wirklich voll wie bei einer SSD implementiert ist, dann müsste gar nichts mehr aus dem Media Cache auf den SMR Bereich kopiert werden, weil die Daten dort ja schon wieder ungültig geworden sind, was dem Controller ja über TRIM mitgeteilt wird.

Das es im Endeffekt nur noch 2 Hersteller gibt für HDDs Weltweit

Es sind 3 nicht zwei, neben WD und Seagate auch noch Toshiba und der Rest des Posts ist auch nicht richtiger.

 

[Akkulaus]

Habe gehört es gäbe 2TB SMR Platten was das, mit 1 Platter dann?

Richtig. Gibt sogar auch 1TB 3,5 Zoll HDD als SMR Platte. Völlig dumm. Preise ändern sich seit Jahren nicht mehr und dann noch sowas.

 

[Holt]

Gibt sogar auch 1TB 3,5 Zoll HDD als SMR Platte.

Und welche? Bei WD gibt es 3.5" mit SMR ab 2TB und nur 2.5" 1TB mit SMR, bei Seagate gibt es die Barracuda und in 3.5" mit 1TB aktuell in Form der ST1000DM010 die laut den Werte im Product Manual definitiv kein SMR hat. Auch bei Toshiba sind die SMR Modelle mit 1TB alles 2.5" HDDs, denn die L200 ist 2.5".

 

[mgutt]

@mgutt Super Bericht, Hut ab!
Eine kleine Winzigkeit: beim Energieverbrauch im letzten Schaubild steht auf der y-Achse Volt. Das sollte Watt heissen?

Jein. Die Volt beziehen sich auf den horizontalen Strich (daher auch die Zahl 230...240... am rechten Rand). Auf der linken Seite des Diagramms steht Watt (und die Zahlen 5..10..), aber das sieht man auf dem Screenshot nicht. Wenn dich der Stromverbrauch interessiert, dann schau in den Test der Ironwolf. Da habe ich das alles gemessen:
https://www.computerbase.de/forum/t...r-test-seit-2019-alternativlos-gross.1950726/

Ergänzung (10. Juni 2020)

Wie hast Du die Partition genau entfernt?

Einfach in der Windows Datenträgerverwaltung. Vielleicht sollte ich mal verschiedene Partionen durchprobieren. Wobei in Windows habe ich da ja nicht viele Optionen.

Die Werte kommen alleine vom Media Cache

Hatte ich das anders erklärt? Das sollte eigentlich auch so in meinem Text rüberkommen.

Wobei man nicht vergessen sollte, dass diese HDD ja auch TRIM unterstützt und CDM die Testdateien am Ende löscht, womit Windows eigentlich die LBAs trimmen sollte die sie vorher belegt hatten und wenn TRIM wirklich voll wie bei einer SSD implementiert ist, dann müsste gar nichts mehr aus dem Media Cache auf den SMR Bereich kopiert werden, weil die Daten dort ja schon wieder ungültig geworden sind, was dem Controller ja über TRIM mitgeteilt wird.

Korrekt, aber das gilt wie gesagt nicht, wenn ich CDM vorher abschieße. Auf die Art bleibt die Datei auf der Platte liegen und die 4K Writes aus dem Media Cache werden verschoben (das passiert sogar schon in der 5-Sekunden Pause zwischen zwei 4K Schreibtests, was man gut hören kann):

Als ich die 2TB an Daten wieder gelöscht und CDM direkt wieder gestartet habe, lag das Benchmark übrigens auch wieder auf Maximum. Also die Schindeln sind sofort wieder verfügbar.

 

[Akkulaus]

Und welche? Bei WD gibt es 3.5" mit SMR ab 2TB und nur 2.5" 1TB mit SMR, bei Seagate gibt es die Barracuda und in 3.5" mit 1TB aktuell in Form der ST1000DM010 die laut den Werte im Product Manual definitiv kein SMR hat. Auch bei Toshiba sind die SMR Modelle mit 1TB alles 2.5" HDDs, denn die L200 ist 2.5".

Stimmt. Da hab ich mich wohl leider verlesen. Aber selbst 2TB SMR ist einfach nur Schwachsinn. Hier gilt einfach nur noch Gewinnmaximierung. Sollen die Hersteller am Geld ersticken...

 

[Holt]

Als ich die 2TB an Daten wieder gelöscht und CDM direkt wieder gestartet habe, lag das Benchmark übrigens auch wieder auf Maximum. Also die Schindeln sind sofort wieder verfügbar.

Nicht die "Schindeln" sondern der Media Cache und da sind die Spuren nicht überlappen, sondern CMR und daher kann man sie doch nicht als Schindeln bezeichnen. Sofern Platz im Media Cache frei ist, dort geschrieben und nicht in den SMR Zonen.

Ergänzung (10. Juni 2020)

Aber selbst 2TB SMR ist einfach nur Schwachsinn.

Nein, denn 2TB gehen mit SMR mit einem 3.5" Platter, ohne SMR derzeit aber noch nicht und dann müsste man zwei Platter nehmen, was die Kosten deutlich steigern würde.

 

[Akkulaus]

Nein, denn 2TB gehen mit SMR mit einem 3.5" Platter, ohne SMR derzeit aber noch nicht und dann müsste man zwei Platter nehmen, was die Kosten deutlich steigern würde.

Um die Kosten zu senken? Sorry. Davon merke ich nix Dann hast du aber ganz schön geschlafen. Für uns bleibt der Preis gleich. Die HDD Preise haben sich seit Jahren kaum geändert. Aber wenn du gerne 2TB SMR Platte haben willst dann bitte. Dann bekomme ich ja 2TB ohne SMR für das selbe Geld.

 

[mgutt]

Nicht die "Schindeln" sondern der Media Cache und da sind die Spuren nicht überlappen, sondern CMR und daher kann man sie doch nicht als Schindeln bezeichnen. Sofern Platz im Media Cache frei ist, dort geschrieben und nicht in den SMR Zonen.

Wenn ich 1TB lösche und sofort wieder 1TB drauf kopiere, kann ich wie zuvor mit 180MB/s schreiben. Daher: Der Media Cache wird nicht für neue Daten verwendet, sondern ausschließlich für Datenänderungen. Der Media Cache ist also kein allgemeiner Schreibpuffer wie zB der TurboWrite einer SSD.

 

[v3nom]

Super Bericht. Hier auch noch was spannendes wo eine SMR Platte in einem ZFS Raid ausgewechselt wurde und das Raid sich neu bauen musste. Ganz schön bitter:
https://arstechnica.com/gadgets/202...r-disks-arent-great-but-theyre-not-garbage/2/

 

[mgutt]

Um die Kosten zu senken? Sorry. Davon merke ich nix

Man weiß natürlich nicht in wie weit die Kosten für WD in der letzten Zeit wirklich gestiegen sind. Aber vom Prinzip kann uns das ja auch egal sein, wenn WD die Kosten senkt, sie aber bei gleicher Leistung nicht an den Endkunden weitergibt. Ein Unternehmen darf von mir aus so viel Gewinn machen wie es will. Was aber gar nicht geht, dass man Kosten und Leistung senkt und den Kunden für dumm verkauft.

Wenn WD zB 2TB CMR Platter hätte und nun statt 5x 1.2TB nun 2x 2TB Platter verbaut, könnte uns das ja echt egal sein. Kombiniert mit mehr Cache und der kleineren Masse, wäre das ja sogar eine deutlich flottere Platte. Dann könnte sie von mir aus den Preis auch so lassen, obwohl sie Geld sparen. Das wäre ja technischer Fortschritt, der auch was kosten darf.

 

[mgutt]

Das folgende Update habe ich oben einfließen lassen. Jetzt mache ich erst mal die Platte komplett voll. Das nächste Update dauert also.

Update 10.06.

Gestern Abend habe ich eine 1GiB große Benchmark-Dateien auf der Platte hinterlassen und danach 1TB an Dateien auf die WD60EFAX kopiert. Damit wollte ich sicher gehen, dass die Schindeln mit den Benchmark-Dateien von den 1TB verdeckt werden. Ich habe dann das Spiel von gestern wiederholt. CDM eingefroren, alte Datei verwenden lassen, 4K Writes abgewartet und abgeschossen. Dann CDM erneut gestartet, eingefroren, alte Datei verwenden lassen und das war das Ergebnis:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_17_34-png.930553/[/IMG]

Aua. Doch warum ist das eigentlich noch langsamer geworden? Lassen wir das doch mit den 4K Writes mal sein:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_29_26-png.930554/[/IMG]

Interessant. Können von anderen Schindeln verdeckte Dateien etwa langsamer gelesen werden? Nein, denn jetzt wird es interessant. Die erste große Datei von den gestern kopierten 1TB kann ich mit 200 MB/s kopieren:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_35_30-png.930558/[/IMG]

Eine in der Mitte mit 180 MB/s:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_36_24-png.930561/[/IMG]

Und die letzte mit 160 MB/s:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_35_53-png.930562/[/IMG]

Wir wissen also, dass die zuletzt kopierten Dateien weiter innen auf dem Platter liegen und daher langsamer kopiert werden. Und genau da liegt jetzt auch unsere Benchmark-Datei. @Holt wird es sicher bestreiten, aber damit bin ich mir sicher, dass wenn das Cache Cleaning läuft, dass dann die Daten nicht in die ursprüngliche SMR Zone kommen, sondern in die nächste freie und erst danach folgt ein TRIM/Garbage Collection um die Zone am Anfang für neue Dateien frei zu machen. Diese Funktion wird von WD LBA indirection genannt, wobei @Holt das nur auf den Media Cache und nicht allgemein auf die SMR Zonen bezieht.

Allerdings kann ich das denke ich noch anders aufzeigen, dass LBA Indirection auch die SMR Zonen betrifft. Denn bevor ich den zuvor genannten Test gemacht habe, hatte ich heute morgen als alle erstes ein Benchmark gestartet und wunderte mich über extrem gute Werte. Über 200 MB/s machen ja keinen Sinn, wenn bereits 1TB an Daten auf der Platte sind:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-09_15_41-png.930506/[/IMG]

Ich wiederholte den Test mehrfach mit dem immer selben Ergebnis. Da ich bereits vermutete, dass wir nun eine freie Spur irgendwo am Anfang der Platte haben, startete ich CDM erneut und beendete den Prozess nach dem 1. Lesetest um die 1 GiB Datei auf der Platte zu behalten. Jeder folgende Benchmark fiel auf 185 MB/s:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-10-11_59_57-png.930571/[/IMG]

Warum dieser Wert allerdings nicht auf 160 MB/s fällt, kann ich nicht erklären. Was aber denke ich klar ist, dass die Benchmark-Datei ihre Position auf den Plattern gewechselt hat, obwohl ich sie nur umbenannt habe und CDM Teile dieser Datei verändert hat. Sie wurde also nicht neu erstellt. Und es gab wie gesagt dadurch eine freie Spur ganz am Anfang der Platte, die jetzt nicht mehr da ist.

... später geht es weiter ...

 

[C4rp3di3m]

HOLT Toshiba Stimmt sorry hab ich mit HGST verwechselt.

mfg

 

[Holt]

Um die Kosten zu senken? Sorry. Davon merke ich nix

Wenn Hersteller die Kosten senken, dann müssen sie dies ja nicht an die Kunden weitergeben, zumal solange noch die Vorgängermodelle auf Lager / im Handel sind und abverkauft werden wollen.

Wenn ich 1TB lösche und sofort wieder 1TB drauf kopiere, kann ich wie zuvor mit 180MB/s schreiben. Daher: Der Media Cache wird nicht für neue Daten verwendet, sondern ausschließlich für Datenänderungen.

Das Fazit würde ich daraus nicht ziehen, denn wie die 4k Schreibend bei CDM zeigen, gingen dort die neuen Daten doch in den Media Cache. Aber ich vermute der Controller schaut wie lang die Schreibzugriffe sind und wenn diese lang genug sind und auf eine SMR Zone geschrieben werden können ohne dabei andere Daten lesen und wieder zurückschreiben zu müssen, dann werden sie vermutlich sofort auch direkt auf die SMR Zone geschrieben, es geht dann ja auch schnell. Langsam wird das Schreiben dort ja nur, durch das Lesen und Zurückschreiben der Daten auf den ungewollt überschriebenen Spuren. Wird eine komplett SMR Zone überschrieben, so geht dies so schnell wie bei CMR und dann braucht man die Daten nicht in den Media Cache zu schreiben und Dank TRIMM kann der Controller ja auch erfahren, dass es auch auf eine SMR Zone die vorher schon einmal beschrieben wurde, eben keine gültigen Daten mehr gibt die er hinterher zurückschreiben müsste.

 

[mgutt]

denn wie die 4k Schreibend bei CDM zeigen, gingen dort die neuen Daten doch in den Media Cache

4K Schreiben sind keine neuen Daten, sondern die Daten der bestehenden Benchmark-Datei werden zu je 4KB Blöcken per Zufall überschrieben. Ich denke, das der Controller das ganz einfach macht. Er erhält vom OS entweder neue Daten ohne Positionsangabe und schreibt diese in neue Zonen oder er bekommt eine genaue Angabe wo die Daten hin sollen (LBA) und in so einem Fall nutzt er dann den Media Cache.

Und dann weiter im Kontext. Ich habe die Festplatte nun komplett befüllt:

Nun sieht HD Tune so aus:

Zum Vergleich noch mal ohne Partition:

Hat einiges eingebüßt.

 

[Holt]

4K Schreiben sind keine neuen Daten, sondern die Daten der bestehenden Benchmark-Datei werden zu je 4KB Blöcken per Zufall überschrieben.

Doch, es sind neue Daten, egal ob der LBA vorher schon beschrieben war oder nicht. Die hohen Ergebnisse zeigen doch klar, dass in den Media Cache geschrieben wird.

Er erhält vom OS entweder neue Daten ohne Positionsangabe und schreibt diese in neue Zonen oder er bekommt eine genaue Angabe wo die Daten hin sollen (LBA) und in so einem Fall nutzt er dann den Media Cache.

Nein, es gibt keine Schreibzugriffe ohne Angabe der LBAs, wie sollte der Host die Daten dann auch jemals wiederfinden? Schau Dir den ATA Befehlssatz an, da gibt es nur Schreibbefehle die einen bestimmten LBA beschreiben oder ab LBA x dann die folgenden y LBAS beschrieben. Es keine Möglichkeit einfach Daten zu schrieben und erst hinterher zu erfahren wo diese geschrieben wurden. Dies man bei den ATA Streaming Befehlen für Echtzeitvideoaufzeichnung oder den besonderen Befehlen für Host Managed SMR anderes sein, aber beides unterstützt die Red ja nicht und Windows meines Wissen selbst auch nicht.

 

[mgutt]

Nein, es gibt keine Schreibzugriffe ohne Angabe der LBAs, wie sollte der Host die Daten dann auch jemals wiederfinden? ... Es keine Möglichkeit einfach Daten zu schrieben und erst hinterher zu erfahren wo diese geschrieben wurden.

Ok, ich ging davon aus, dass die API dann einfach mit dem entsprechenden LBA Bereich(en) antwortet. Zugegeben habe ich einfach keine Website gefunden, die das mal an Hand von Beispielen wie das OS mit der HDD API kommuniziert erklärt.

Zumindest weiß aber der HDD Controller, dass der vom Betriebssystem gewünschte LBA (bzw vom HDD Controller dafür zugewiesene Sektor) belegt oder eben noch frei ist. Daran könnte er es ja ausmachen ob er in die SMR Zone oder auf den Media Cache schreibt.

Die hohen Ergebnisse zeigen doch klar, dass in den Media Cache geschrieben wird.

Ja, aber nur die 4K Writes und nicht die sequentiellen. Du sagtest ja, dass das nicht nur für Datenänderungen gilt. 4K Writes sind ja Datenänderungen und keine komplett neue Daten an neuen LBA-Positionen.

Dass er nur in den Media Cache schreibt, wenn 4K Writes, also kleine Datenänderungen, gemacht werden, halte ich alleine deswegen für bewiesen, weil das Cache Cleaning immer nur dann startet, wenn CrystalDiskMark die 4K Writes beendet. Hier der Verlauf vom Stromverbrauch während CDM lief:

Nach dem letzten Benchmark würde er eigentlich mit dem Cache Cleaning weitermachen, aber CDM hat dann ja die Benchmark-Datei gelöscht (und damit auch den Media Cache). Wenn ich dagegen CDM über den Ressourcen-Monitor abschieße, läuft wie gesagt das Cache Cleaning noch über eine Minute weiter.

Wenn ich zB CDM mit mehreren Durchläufen nur den sequentiellen Read und Write machen lasse und den Prozess abschieße, so dass die Benchmark-Datei erhalten bleibt, dann kommt es niemals zum Cache Cleaning. Also auch nach vielen Minuten nicht.

Hast du eine Idee wie ich messen könnte wie viel MB beim 4K Write auf die Festplatte übertragen wird? CDM ermittelt zwar 11 MB/s, aber ich weiß ja nicht wie viele Sekunden CDM gearbeitet hat und wie groß der Overhead bei 4K-Dateien ist. Ich würde gerne die HDD mit 4K Writes zubomben um zu messen wie viel MB/GB es braucht um den Media Cache vollzuschreiben. EDIT: Ich hatte eine Idee. Ich habe mit "ECMerge" die Benchmark-Datei vor und nach dem 4K Write verglichen. Es unterscheiden sich allerdings nur 13490 Bytes, also knapp 14KB der 1 GiB großen Datei. Also scheint CDM die 4K Writes größtenteils mit den selben Daten durchzuführen, die bereits vorhanden sind. Auf die Art kommen ich also nicht dahinter wie viel in Summe geschrieben wurde 😤

 

[Bigeagle]

Interessant und etwas gruselig. Wenn die HDD garnicht mehr liest, sondern die Daten aus anderen Daten ableitet ...
Beißt sich das nicht eventuell mit z.b. versteckten Partitionen (truecrypt/veracrypt z.b.) und allgemein allen ungewöhnlichen lowlevel zugriffen?

Allerdings finde ich es garnicht so überraschend dass HDTune da mist misst, weil das eben nur kleine blöcke in größeren abständen liest/schreibt. Das sollte ein Schreibcache auf dem Medium komplett abfangen können. Dass das auch lesend schief geht ist unerwartet und eher grenzwertig schwarze magie, da man nicht das bekommt was man wollte, sondern nur was der controller glaubte das man will.

Gäbe es Interesse/Bereitschaft einen eigenen Benchmark zu entwickeln und zu testen?

Ich fand die klassischen Speicherbenchmarks wie HDTune, Atto, Crystaldiskmark usw eher suboptimal für SMR-spezifische Tests weil die eben entweder nur sehr kleine Datenmengen nutzen. Ich kann ein bisschen python, warum also nicht etwas eigenes schreiben wo man dann gezielter Datenmenge und Zugriffsmuster einstellen kann? Ein einfaches Script sollte auch vertrauensproblemen vorbeugen.

Anspruch wäre nicht absolute Genauigkeit, sondern Aufzeigen von solchen SMR Effekten, wobei Caches durch eine Anpassung der zu bearbeitenden Daten sicher umgangen werden können. Da sollte ein dateibasierter Amateurbenchmark ausreichen.

Grundidee ist
1: X Dateien mit Größe Y anlegen
2: zufällig oder sequentiell diese dateien öffnen, änderungen vornehmen, speichern
3: zufällig oder sequentiell diese dateien vergrößern (daten anhängen)

Anzahl und Größe wären mindestens im script einfach änderbar. Bei genug Zeit und interesse könnte man auch eine externe config datei ermöglichen. Diese Anpassungen und die arbeitsweise in Dateihäppchen würden das ganze von den Benchmarks die mit einer einzelnen, max wenige GB großen Testdatei arbeiten ebenso abheben, wie von einem einfachen vollschreiben mit dd.
Dazu noch ggf interessante Stats wie Zeiten für die jeweiligen Dateien, unterschiedliche optionen für die Struktur (nicht jedes FS mag es wenn zigtausende Dateien in einem Ordner liegen) und was einem noch einfällt.
Testdaten würde ich der Einfachheit halber immer pseudozufällig wählen, aber erstmal nur eine Datei vorgeneriert. Das sollte reichen um eine eventuelle Kompression auszuhebeln solange die Dateigröße > Blockgröße der Kompression bleibt. Wer mit aktiver Kompression und Deduplizerung einen Dateibasierten Benchmark macht muss sich eine schnellere Zufallsquelle besorgen, ansonsten besteht die Gefahr bis Gewissheit dass die CPU anstelle der Platte limitiert.

1. liefert vor allem die Testbasis und den Durchsatz. Dazu sollte damit ein CMR Cache bei SMR Platten gefunden werden können.
2. testet die leistungseinbußen bei änderungen, hier sehe ich vor allem den Vergleich zwischen Platten als interessant an.
3. was das genau testet weiß ich garnicht, erschien mir aber als logischer und leicht zu implementierender zusatzschritt der durchaus auch praktisch relevant ist. Da spielen langsam auch ziemlich viele Faktoren mit rein, wie geht das Dateisystem damit um? Wird die Datei da sie nun zu groß für ihren alten Platz ist komplett woanders hin geschrieben, oder kommt nur der neue Teil woanders hin?

Erwartungen wären:
1. Bei SMR mit Cache gibt es nach einer bestimmten Datenmenge einen Einbruch in der Schreibrate. Ggf auch nachlaufaktivität die man entweder mit einem anderen Tool feststellen müsste, oder jemand mit mehr ahnung und motivation als ich sie habe müsste die erkennung einbauen. Ohne Cache sollte bei ausreichend geringer Dateigröße Y von anfang an ein verringerter Durchsatz erkennbar sein da die Schindelabschnitte (ich hoffe das ist verständlich) nicht am stück vollgeschrieben werden.
2. Abhängig vom Dateisystem sollten SMR Platten spätestens nach vollaufen eines Caches deutlich langsamer werden. Bei Copy on write Dateisystemen sollte praktisch das gleiche ergebnis wie bei 1. zu sehen sein. Die sequentielle Änderung der Dateien sollte bei CMR gleichschnell oder schneller sein als bei zufälliger Reihenfolge, Abhängig von der Dateigröße und Größe der Änderungen. Bei SMR sollte bei einem Cache gleichstand zwischen sequentieller und zufälliger Reihenfolge herrschen.
3. Bei Copy on Write sollte das ergebnis Test 1 ähneln, andernfalls sollte die verlangsamung bei SMR geringer ausfallen da eine serialisierung der daten stattfindet - die angehängten daten würden hinter die in 1. geschriebenen daten geschrieben und sollten unabhängig von der Reihenfolge sein.

Ansonsten sollte sich eine cachelose SMR Platte wie eine CMR Verhalten wenn man die Größe der Schreibzugriffe genau auf die Größe der Schindelabschnitte abpasst. Mit Cache kommt es darauf an ob die den bei sequentiellen/großen Zugriffen umgehen.

Besonders aber würde ich erwarten dass man deutlich Unterschiede in der Implementierung von SMR und Caches erkennen kann.