WD60EFAX: Wenn Benchmarks bei SMR-Platten versagen

Holt

Banned
Dabei seit
Mai 2010
Beiträge
59.527
Zitat von mgutt:
die das mal an Hand von Beispielen wie das OS mit der HDD API kommuniziert erklärt.
Was Du API nennst, ist der ATA Befehlssatz, den findest Du im Internet auch ganz einfach.
Zitat von mgutt:
Ja, aber nur die 4K Writes und nicht die sequentiellen.
So viel geringer als die Lese- sind die sequentiellen Schreibraten nun auch nicht.
Zitat von mgutt:
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.
Nein, wo habe ich dies gesagt? Im Gegenteil war meine Aussage:
Zitat von Holt:
Doch, es sind neue Daten, egal ob der LBA vorher schon beschrieben war oder nicht.
Ob schon vorher Daten für den LBA geschrieben wurden oder nicht, spielt keine Rolle, wenn auf einen LBA geschrieben wird, dann sind das immer neue Daten.
Zitat von mgutt:
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.
Ist nicht erst nach dem 4k Test der Benchmarklauf beendet und das der Media Cache erst im Idle geleert wird, sollte doch schon bekannt sein.
Zitat von mgutt:
Hier der Verlauf vom Stromverbrauch während CDM lief:
Ob man das Leeren des Media Caches wirklich an der Leistungsaufnahme sehen kann?
Zitat von mgutt:
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.
Müsste es aber, daher glaube ich nicht, dass man anhand der Leistungsaufnahme das Cache Cleaning sehen kann.
Zitat von mgutt:
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.
Bei 4k ist der Overhead höher, aber was genau willst du wirklich messen? Es gibt ja gerade bei SMR HDD mit Media Cache nicht nur einen, sondern schon bei jeder HDDs auf unterschiedlichen Spuren auch unterschiedliche 4k Werte (wie auch unterschiedliche sequentielle Transferraten) und dazu noch im Media Cache und in den SMR Zonen stark unterschiedliche Werte.
Zitat von mgutt:
Ich würde gerne die HDD mit 4K Writes zubomben um zu messen wie viel MB/GB es braucht um den Media Cache vollzuschreiben.
Da müsste man mal schauen welcher Benchmark die kann, IOMeter dürfte es können, aber ich kann dir auch nicht aus den Kopf sagen wie man dies nun machen muss, IOMeter ist ja recht kompliziert zu bedienen.
Zitat von mgutt:
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.
Solche voreiligen Schlussfolgerungen ohne genau Kenntnis oder auch nur eine Analyse sind typisch für dich und führen dich immer wieder in die Irre. Denn CDM brecht im Vergleich zu AS-SSD bei langsamen Medien wie HDDs nur recht kurz (benche mal mit dem AS-SSD Benchmark und schau wie lange der 4k Test da dauert), ohne den Quellcode analysiert zu haben, würde ich ein Zeitlimit im Spiel ist und daher so wenig geschrieben wird. Zum Test kannst Du ja mal den gleichen Test auf einer SSD machen und schauen ob immer noch nur 14k bei 1GiB rauskommen, wobei ich ECMerge nicht kenne, ich würde die Datei einfach nur mal komprimieren um zu sehen wie viele Daten wirklich drin sind.
Zitat von Bigeagle:
Interessant und etwas gruselig. Wenn die HDD garnicht mehr liest, sondern die Daten aus anderen Daten ableitet ...
Wie kommst du da drauf?

Mehr von dem Post habe ich nicht gelesen und ich denke, dies sollte jeder andere auch so handhaben, denn hier geht viel durcheinander, weil Unwissenheit und Fehlinterpretationen zu reichlich Unsinn führen.
 

Bigeagle

Lt. Commander
Dabei seit
Nov. 2008
Beiträge
1.307
Zitat von Holt:
->
Zitat von mgutt:
Doch wie @Holt schon richtig vermutete, antwortet die WD60EFAX einfach mit "Null", wenn der Sektor noch nicht beschrieben wurde.
-> Der Controller leitet den Wert des Sektors daraus ab ob er beschrieben ist und nicht anhand des tatsächlichen Inhaltes.
Ansonsten bräuchte es immer noch eine erklärung für die etwas sehr schnellen 380 MB/s im ersten Test.
Wobei ich mich schon frage wie die HDD an das Wissen vom Dateisystem kommt. Jeden Sektor flaggen wenn er das erste mal beschrieben wurde klingt unsinnig.

Zitat von Holt:
Mehr von dem Post habe ich nicht gelesen und ich denke, dies sollte jeder andere auch so handhaben, denn hier geht viel durcheinander, weil Unwissenheit und Fehlinterpretationen zu reichlich Unsinn führen.
Wenn du mir sagen könntest wo dort Unsinn steht wäre das sehr nett ;)
Einfach Dateien schreiben und gucken wie lange das dauert dürfte ein sehr naheliegender Ansatz sein um die Geschwindigkeit einer Platte zu messen, selbst CB hat einen solchen Kopierbenchmark ;)
Der einzige Unterschied ist dass man für SMR mehr haben will als nur am Stück schreiben und dass die Größe der Stücke eine zusätzliche Rolle spielt. Ansonsten ist das nur der Versuch einen Mittelweg zwischen bestehenden synthetischen Benchmarks und schlecht reproduzierbarer praktischer nutzung zu finden ohne den Aufwand zu betreiben und tatsächlich Zugriffe aus der Praxis aufzuzeichnen und nachzustellen.
 

Holt

Banned
Dabei seit
Mai 2010
Beiträge
59.527
Zitat von Bigeagle:
Der Controller leitet den Wert des Sektors daraus ab ob er beschrieben ist und nicht anhand des tatsächlichen Inhaltes.
Das macht jeder SSD Controller genauso, wenn ein LBA nie beschrieben (oder wieder getrimmt) wurde, dann steht der LBA gar nicht mehr in der Mappingtabelle und der Controller wüsste gar nicht, wo er Daten dafür auslesen sollte. Wo ist das Problem, wenn die HDD dies nun auch macht? Normalerweise stehen bei nagelneuen HDDs auf allen Sektoren nur Nullen, wenn eine Sektor also nie überschrieben wurde, dann würde die HDD beim Auslesen sowieso nur Nullen zurückgeben, wenn der nun weiß das dieser Sektor nie beschrieben (oder wieder getrimmt) wurde und die Nullen direkt ausgibt, wo ist das Problem? Nur kann man das Wiederherstellen von versehentlich gelöschten Dateien dann vergessen, wenn TRIM aktiv war, aber bei SSDs ist dies doch genauso.
Zitat von Bigeagle:
Wobei ich mich schon frage wie die HDD an das Wissen vom Dateisystem kommt. Jeden Sektor flaggen wenn er das erste mal beschrieben wurde klingt unsinnig.
Den Aufwand sich selbst für jeden Sektor zu merken ob der jemals beschrieben bzw. ggf. danach wieder getrimmt wurde, halte ich auch für so groß, dass ich mir dies eigentlich nicht vorstellen konnte. Dazu hatte ich im anderen Thread schon mal geschrieben:
Zitat von Holt:
Das einzige was mich interessieren würde wäre, wie sie das mit dem TRIM handhaben. Der Sinn ist klar, Sektoren die getrimmt wurden, braucht nicht mehr eingelesen und zurückgeschrieben werden, wenn sie ungewollt überschrieben werden, eben weil die sie überlappende Nachbarspur überschrieben wird. Es bringt erst richtig was, wenn alle Sektoren einer Spur getrimmt sind, dann kann man deren sie überlappende Nachbarspur nämlich wie bei CMR einfach nur überschreiben. Aber 6TB bedeutet über 11,5 Milliarden Sektoren, also fast 12GB an Daten wenn man ein Byte pro LBA speichert und selbst wenn es nur ein Bit ist, sind es noch 1,5GB an Daten und damit viel zu viel für die 256MB des DRAM Cache. Bei jedem TRIM Befehl muss also irgendwo auf die HDD geschrieben werden, was wegen der Kopfbewegungen die Performance auch nicht verbessert und dann muss ja in den Daten auch wieder vermerkt werden, wenn der Sektor mit neuen Daten beschrieben wurden, dies hebt das TRIM ja wieder auf, wird ein LBA getrimmt bedeutet dies ja, dass seine Daten ungültig sind, die Datei zu der sie gehört haben, wurde ja gelöscht, der Controller muss sie also nicht erhalten, aber wenn neue Daten auf dem LBA geschrieben werden, dann sind diese wieder gültig und müssen erhalten blieben. Schreibt man diese Information auf einen gesonderten Bereich, so muss dieser bei jedem TRIM oder Schreibbefehl auch angefahren und überschrieben werden. Schreibt man es aber zu den Daten den Sektoren, dann wäre es zwar beim Schreiben neuer Daten einfach, aber beim TRIM müsste man ja wieder die anderen Sektoren einlesen und neu Zurückschreiben, die Spuren sich ja nun einmal überlappen und dann würde jeder TRIM Befehl extrem lange brauchen um ausgeführt zu werden, dies wäre also nicht praktikabel, aber immer nur wegen TRIM eine anderen Position anfahren und dort 1,5GB Daten zu lesen oder ggf. zu überschreiben, könnte mehr Performance kosten als man am Ende gewinnt, denn es würde immer Performance kosten, ob man sich das Lesen und zurückschreiben eines Sektors sparen kann, ist dagegen ungewiss.
Nun findet mgutt beim Testen raus, dass es beim Lesen mit HD Tune einen gewaltigen Unterschied macht ob eine Partition vorhanden ist oder nicht, mit einer leeren Partition kommen über 350MB/s über die ganze Kapazität raus, so schnell kann keine 3.5" HDD lesen und schon gar nicht konstant von den äußersten bis zu den innersten Spuren, da wird also offensichtlich gar nicht von der Platte selbst gelesen, wohl aber wenn die Partition gelöscht wurde. Also scheint der Controller die Partitiontabelle und wertet auch das Filesystem und die Belegung aus, wie der Test bei dem mit 2,5TB befüllt war, nahe legt:

2020-06-08 14_03_35 WD60EFAX_SRM_mit ca 2.5TB Daten gefüllt.png


Allerdings muss die Platte dann eigentlich verschiedene Filesysteme unterstützen wenn es nicht nur unter Windows klappen soll und wenn sie in einem RAID 0, 5 oder 6 läuft, dann klappt es nicht mehr und kann ggf. wirklich gefährlich werden, da ja bei ausreichend großem Stripesize die Partitiontabelle komplett auf einer der Platten des RAIDs steht. Wenn der Offset der ersten Partition klein genug ist, dann steht so Kennung des Filesysteme dort. Die Adressen stimmen aber natürlich nicht, ein RAID 0 aus zwei der 6TB ist ja 12TB groß und die Partitionstabelle kann Daten jenseits der Kapazität der HDD enthalten auf der sie steht, was ggf. auch diesen komischen "IDNF" ("Sector ID not found") Fehler erklären könnte. Der käme dann gar nicht daher das der Host einen LBA adressiert hat den es nicht gibt, die RAID Lösung (egal ob HW oder SW RAID) rechnet die globalen Adressen des RAIDs (die so ja auch in der Partitionstabelle und allen anderen Metadaten auf dem RAID stehen) in die lokalen Adressen der einzelnen Platten um, aber wenn der Controller selbst versucht die Metadaten auf der Platte auszuwerten, dann findet er ggf. dort Adressen die über den eigenen Adressraum hinausgehen, die Platte weiß ja nicht, dass sie Teil eines RAIDs ist, aber an der Stelle könnte der Controller dies merken und abbrechen statt so einen Fehler auszugeben.

Nur wenn der Controller in Wahrheit die Metadaten auf der Platte auswertet, wozu dann die TRIM Untersützung? Nur als Ablenkung? Beim Entfernen einer Partition aus der Partitiontabelle wird ja nicht getrimmt, dies passiert erst beim Schnellformatieren, was man üblicherweise macht wenn man eine Partition anlegt.

mgutt, beim Test mit den 2,5TB Daten war da doch eine große Partition drauf oder? Kannst Du den nochmal wiederholen und danach die Dateien im Explorer löschen und erneut mit HD Tune benchen? Führe ggf. vorher ein Schnellformat aus um alles zu trimmen. Wärst Du auch in der Lage unter Linux zu benchen?
 

Crass Spektakel

Lieutenant
Dabei seit
Juli 2015
Beiträge
915
Querverweis auf https://www.computerbase.de/forum/threads/keine-smr-laufwerke-fuer-steam.1988626/

Ich habe jetzt schon bei zwei Drive-Managed-SMR-Laufwerken erlebt daß man die mit Secure-Erase wie eine Festplatte zurücksetzen kann. Anschliessend sind die Laufwerke eine ganze Weile deutlich reaktionsfreudiger als bei einem simplen Löschen/Formatieren einer Partition.

https://www.thomas-krenn.com/de/wiki/SSD_Secure_Erase

Ich schätze daß SMR-Laufwerke sich dabei sehr ähnlich einer SSD verhalten, d.h. logische und physikalische Sektoren haben mitunter wenig miteinander zu tun. Und anhanden der Test-Daten bin ich verwundert wie klein die CMR-Caches sind. Ich hätte ja geschätzt daß doch 10-20% der Platte als CMR-Cache genutzt würden aber das ja bestenfalls ein paar zig Gigabyte.

Ganz anderes Ding, Host-Managed-SMR-Laufwerke sind durchaus witzig wenngleich für Otto-Normalverbraucher eher uninteressant. Die WD-Modelle arbeiten dabei wie folgt:

Physikalisches Laufwerk erscheint als zwei Laufwerke, eines rein CMR, eines rein SMR.

Dabei war zumindestens der CMR-Teil immer native-4096-Bytes-Sektoren und der SMR-Teil arbeitete mit Sektoren von 64 bis 256(!!!) Megabyte.

Auf den 4096Byte-CMR-Sektoren kann man ganz normal mit einem Filesystem arbeiten. Aber mit dem SMR-Teil mit 256MByte-SMR-Sektoren kommt natürlich kein Filesystem zurecht. Mit "tar -b x" oder "dd bs=y" bei manuell vorgegebener Blockgrösse aber läuft das einwandfrei und vor allen Dingen SAUSCHNELL. Mit "dd bs=128m" habe ich durchgehend Raten von über 200MByte/s erreicht bis die Platte voll war. Ich schätze daß da hinter jedem "Block" eine komplette SMR-Spindel liegt.

Interessanterweise benimmt sich der SMR-Teil fast perfekt wie ein Bandlaufwerk. Bacula erkennt es auch als solches aber gut, das erkennt inzwischen auch USB-HDs als Bandlaufwerk. Aber sogar die uralten SCSI-Befehle für "Spulen" sind implementiert, ein "mt fsf 1" setzt den Lesekopf ungelogen auf die nächste "Tape-Session". Anscheinend ist der SMR-Teil wirklich als Bandlaufwerksersatz implementiert wodurch das Gerät ausgezeichnet von Tapebackupsoftware unterstützt wird.

Mit einem Tool vom Anbieter des Storage-Systems und einem anschliessendem Secure-Erase kann man das Verhältnis SMR zu CMR frei wählen. Das ist allerdings spezifisch für dieses Storage-System, ob das auch mit hdparm/smartctl/scsicodepage geht habe ich nicht rausgefunden. Im Falle der WD-Datacenter-Platten ging das sogar so weit daß man den SMR-Teil auf Null setzen konnte und dann eine CMR-Platte mit etwa 20% geringerer Kapazität aber gewaltigem 512MByte Cache bekommt. Oder man verzichtete auf den CMR-Teil und bekam ein "Bandlaufwerk" mit etwa 5% mehr Kapazität als auf der Verpackung versprochen. Aktiv getestet habe ich das aber nicht da das ein Produktivsystem war. Ich habe immer bei "are you sure" abgebrochen.

Edit: Die SMR/CMR-Bereiche sind natürlich nicht auf Partitionsebene getrennt sondern erscheinen als FIS-based-switched SATA-Device als hätte man zwei physikalisch getrennte Harddisks am Kabel. Kann sein daß das vom Storage-System eingeblendet wurde aber das glaube ich nicht weil ich mit smartctl -d <deviceoverride> eigentilch sauber mit den Einzelbereichen arbeiten konnte.
 
  • Gefällt mir
Reaktionen: AlphaKaninchen
Top