News Western Digital: Sammelklage wegen heimlichen SMR-Festplatten

[Holt]

Genau das passiert nicht. Sonst wäre der CDM Random nicht so krass gut (für eine HDD)

Da hast Du meine Aussage aber komplett aus dem Zusammenhang gerissen, die Aussage "die Daten werden aber sofort wieder zurückgeschrieben, nachdem sie wegen des Schreiben des überlappenden Nachbarsektors überschrieben wurden." bezieht sich auf das Schreiben in der SMR Zone. Dies sollte auch darauf ersichtlich sein, dass es nur dort überlappende Spuren gibt. Das hat also nichts mit dem Random Write Werte zu tun, denn:

Entweder landen die Random Writes in der CMR Zone (Write Buffer)

Richtig, das schreib ich doch auch:

Das erreichst Du ja schon durch die Pause, wenn die HDD dann wirklich Idle ist, nur sind SMR HDDs lesend eben nicht langsamer und wenn CDM dann wieder schreibt, etwa beim 4k Test, dann landen diese Daten wieder im OnDisk Cache, auch wenn die alten Daten schon im SMR Bereich liegen.

Für die Daten dort gibt es eine Indirection Table, es ist ja ein Cache und daher muss man wie bei jedem Cache auch immer wohin diese Daten gehören und wie bei jedem Schreibcache, werden sie irgendwann aus dem Cache auf ihre finale Position kopiert, nur ist eben diese finale Position meiner Ansicht nach auch bei WD HDDs für einen bestimmten LBA immer genau der gleiche physikalische Sektor und nicht mal dieser und mal ein anderer.
Deswegen sind die Schreibraten bei den 4k bei HDDs mit OnDick Cache ja auch so hoch, während bei normalen CMR Platten immer erst die richtig Position angefahren werden muss, kann man die Daten einfach hintereinander in den OnDisk Cache schreiben, da ja dabei steht für welchen LBA sie sind und sie dann hinterher dorthin geschrieben werden. Aber lass man den OnDisk volllaufen und wiederhole den 4k Benchmarks dann, da werden dann aber richtig miese Werte bei Rauskommen, da dann nämlich im SMR Bereich geschrieben werden muss und wenn da schon Daten stehen, bedeutet dies diese vorher zu lesen und hinterher zurückzuschreiben.

Naja, normal sieht das in HD Tune jedenfalls nicht aus

Wo kommt denn das Bild her? Über 300MB/s sind natürlich Quatsch, keine 3.5" HDD schafft so hohe Transferraten und schon gleich gar keine mit nur 5400rpm. Entweder ist die leer und komplett getrimmt und der Controller weiß dann wirklich das er keine Daten von der Platte zu lesen braucht und antwortet einfach mit Nullen wie es SSDs i.d.R. ja auch machen.

Ich denke, dass die Daten mit der Zeit massiv fragmentieren, wenn kein Trim bzw WD sagt ja Garbage Collection ausgeführt wird.

Erstmal sind TRIM und Garbage Collection zwei verschiedene Dinge, auch bei SSDs! TRIM sind Befehle mit denen der Host (also PC, NAS, etc.) der Platte mitteilen kann, dass bestimmte Daten nicht mehr gebraucht werden, im Alltag eben weil die Datei zu der sie gehören, gelöscht wurde. Die Garbage Collection, die man sonst eigentlich nur bei SSDs hat, aber das Leeren des OnDisk Cache könnte man ja auch als Garbage Collection betrachten, nutzt diese Information dann um diese Ungültig gewordenen Daten bei SSDs nicht noch unnötig umzukopieren wenn ein NAND Block gelöscht wird und bei SMR HDDs eben um sie nicht erst lesen und danach zurückschreiben zu müssen, wenn sie wegen der Überlappung überschrieben wurden.

Ich habe mir jetzt einfach mal eine WD60EFAX bestellt. Sag mir was ich testen soll. Dann kommen wir schon dahinter

Gleich nach Einbau könntest Du den Screenshot von CrystalDiskInfo ziehen, dann sieht man auch ob sie wirklich neu oder ein Rückläufer ist und dann einmal HD Tune (aber nicht die alte 2.55 Freeware, die nur bis 2TiB adressieren kann) lesen drüber laufen lassen. Vielleicht bekommen wir ja dann das gleiche Bild wie Du es gepostet hast, dann wäre klar das der Controller der HDD weiß wo gültige Daten stehen und wo nicht.

Danach könntest Du sie mit TrimCheck prüfen, man lässt es zweimal laufen, beim ersten mal wird die Testdatei erzeugt und gelöscht, beim zweiten mal wird geschaut ob TRIM funktioniert hat, dazu sollte man der Platte vielleicht 1 Minute Zeit lassen. Nur die Ausgabe des zweiten Laufs ist interessant, die des ersten nicht.

Erst sagst du, dass TRIM nichts verschiebt und dann sagst du, dass die Testdaten vom OnDisk Cache auf die finale Position kommen. Häh?

Was hat TRIM mit dem Verschieben der Daten aus dem Schreibcache zu tun? NICHTS! Du scheinst die Bedeutung von TRIM nicht zu kennen und es mit dem was WD Garbage Collection nennt zu verwechseln, aber es ist ganz was anderes, übrigens auch bei SSDs und ob WD mit Garbage Collection wirklich das Leeren des OnDisk Caches meint, kann ich auch nicht sagen.

Genau das will ich ja erreichen. Ich will, dass die Testdatei von der CMR Zone, die du OnDisk Cache nennst auf den Backstore (SMR Zone) kommen, den du finale Position nennst. Also werden ja die Daten verschoben. Oder du musst doch noch mal genauer erklären. kopfkratz

Jetzt weiß ich gerade nicht wo ich auf die Bezeichnung OnDisk Cache gestoßen bin, jedenfalls erinnere ich mich in diesem Artikel von Anandtech vom July 2014 erstmal auf die Rechnologie gestoßen zu sein, die HGST "disk-based media cache" nannte.

CMR zones hätte man es nicht nennen können, da die damals für CMR HDDs war und da sind alle Spuren CMR. Ich muss es wohl im Zusammenhang mit den Seagate Archive gelesen haben, finde es aber gerade nicht, dafür habe ich dieses alten Datenblatt von 2016 für die Seagate Mobile (2.5") HDDs gefunden in dem klar die Spalte "SMR Technology, Drive-Managed" vorhanden und YES angegeben ist. Da wurde es also nicht verschwiegen.

Aber das Daten aus dem Schreibcache, ob man ihn Media Cache oder OnDisk Cache oder CMR Zones nennt ist ja egal, dann irgendwann an ihre Position im SMR Bereich geschrieben werden, ist klar und bedeutet nicht das Verschieben von dem du sprichst wo es darum geht an welcher Position diese Daten auf der Platte stehen. Da sage ich klar: Daten die unter dem gleichen LBA geschrieben wurden, werden dann am Ende auf dem gleichen physikalischen Sektor landen und nicht mal auf einem in einer SMR Zone und mal auf einem in einer anderen SMR Zone! Ganz einfach weil man sonst den Aufwand mit einer Mappingtabelle hätte wie bei einer SSD und so muss man nur den Inhalt des OnDisk Cache verwalten, also wissen zur welchen LBAs die Daten gehören die im OnDisk Cache stehen und wo sie da stehen um bei Lesen dieser LBAs auch die richtigen Daten, nämlich die zuletzt geschrieben die noch im OnDisk Cache stehen, zu lesen und nicht ggf. die alten Daten im SMR Bereich die noch überschrieben wurden, weil der OnDisk Cache noch nicht geleert wurde. Ob WD diese Leeren des OnDisk Cache als Garbage Collection bezeichnet, weiß ich nicht, kann sein, jedenfalls wäre es das einzige was irgendwie einer Garbage Collection wie bei einer SSD nahe kommt, auch wenn SSD Controller dabei die Daten intern auf andere NAND Pages kopieren um den NAND Block löschen zu können in dem die vorher standen, aber SSDs haben ja auch eine vollständige Mappingtabelle über ihren gesamten Adressraum.

 

[AlphaKaninchen]

@Holt , @mgutt Ich finde es übrigens echt amüsant wie ihr beide euch in nahezu jedem Thread zu SMR HDDs bisher in missverständnisse Verlaufen habt

Aber zum sinnvollen...

Erstmal sind TRIM und Garbage Collection zwei verschiedene Dinge, auch bei SSDs! TRIM sind Befehle mit denen der Host (also PC, NAS, etc.) der Platte mitteilen kann, dass bestimmte Daten nicht mehr gebraucht werden, im Alltag eben weil die Datei zu der sie gehören, gelöscht wurde.

Danke ich habe oben nämlich auch schon gerätselt warum man auf den TRIM warten soll wenn man einfach:

sudo fstrim -v <Pfad zum Verzeichnis z.B. /media/SMRHDD/>

machen kann

Aber das Daten aus dem Schreibcache, ob man ihn Media Cache oder OnDisk Cache oder CMR Zones nennt ist ja egal, dann irgendwann an ihre Position im SMR Bereich geschrieben werden, ist klar und bedeutet nicht das Verschieben von dem du sprichst wo es darum geht an welcher Position diese Daten auf der Platte stehen. Da sage ich klar: Daten die unter dem gleichen LBA geschrieben wurden, werden dann am Ende auf dem gleichen physikalischen Sektor landen und nicht mal auf einem in einer SMR Zone und mal auf einem in einer anderen SMR Zone! Ganz einfach weil man sonst den Aufwand mit einer Mappingtabelle hätte wie bei einer SSD und so muss man nur den Inhalt des OnDisk Cache verwalten, also wissen zur welchen LBAs die Daten gehören die im OnDisk Cache stehen und wo sie da stehen um bei Lesen dieser LBAs auch die richtigen Daten, nämlich die zuletzt geschrieben die noch im OnDisk Cache stehen, zu lesen und nicht ggf. die alten Daten im SMR Bereich die noch überschrieben wurden, weil der OnDisk Cache noch nicht geleert wurde. Ob WD diese Leeren des OnDisk Cache als Garbage Collection bezeichnet, weiß ich nicht, kann sein, jedenfalls wäre es das einzige was irgendwie einer Garbage Collection wie bei einer SSD nahe kommt, auch wenn SSD Controller dabei die Daten intern auf andere NAND Pages kopieren um den NAND Block löschen zu können in dem die vorher standen, aber SSDs haben ja auch eine vollständige Mappingtabelle über ihren gesamten Adressraum.

Aber das ist doch ein Physikalisches Verschieben also der CMR OnDisk Cache liegt doch wo anderst als der Sektoren in den die Daten müssen? Klar nach außen ist es die selbe LBA und wenn es auf dem finalen Sektor ist auch immer die gleiche Position auf der Platte, aber der CMR Cache ist doch nicht an der finalen Position?

 

[mgutt]

Gibt es ein gutes Benschmark Tool für Linux, mal abgesehen von Gnome Disks, was intern ja auch nur dd machen dürfte...

Ja und es ist für unseren Test sogar perfekt:
https://unix.stackexchange.com/a/392091/101920

Du musst nur den Löschbefehl nach fio weglassen. Dann bleibt die Testdatei auf der Platte. Nun muss die Platte dazu gebracht werden die Daten von CMR auf SMR zu schieben. Danach wie gesagt einen Haufen Dateien drauf schieben, damit die Testdatei-Schindeln "überschindelt" werden ^^

Wenn du dann fio erneut ausführst, müsste sich erstmal nichts ändern, da die 4K Writes als letztes ausgeführt werden. Aber wenn du fio ein drittes mal ausführst, erwarte ich, dass die 4K Writes auf der CMR Spur liegen und der Rest noch auf der SMR Spur und dadurch die sequentiellen Reads durch den ständigen Spurwechsel zumindest minimal einbrechen, da die CMR Spur wie @Holt sagt mehrfach jeweils in der Nähe von den SMR Spur-Gruppen ist.

 

[Holt]

Aber das ist doch ein Physikalisches Verschieben also der CMR OnDisk Cache liegt doch wo anderst als der Sektoren in den die Daten müssen?

Ja und ich habe auch nie was anderes beschrieben als das die Daten von dort an ihre Position im SMR Bereich geschrieben werden, dies ist bei jedem Cache der ein Schreibcache ist, ja nicht anders. Im Cache der CPU stehen ja auch Daten aus dem RAM die aus ganz unterschiedlichen RAM Bereichen sind und wenn die CPU etwas ändert, wird dies dann an die korrekte RAM Adresse zurückgeschrieben.

Aber mgutt meint nach meinem Verständnis etwas anderes:

Allerdings meint LBA Indirection explizit das Schreiben der Daten in den nächsten freien Block in dem die Zurodnung geändert wird
...
Dieses umfasst die Defragmentierung dieser auf dem Datenträger schlussendlich stark verstreuten LBA Gruppen

Da habe ich meine Zweifel, da es bedeuten würde, dass eine volle Mappingtabelle vorhanden sein müsste und die sind viel größer als die DRAM Caches der HDDs und während schon bei den DRAM Less SSDs die sich den passenden Teil aus dem NAND holen müssen die Performance teils grottig ist, möchte ich mir nicht vorstellen was los wäre wenn eine HDD erst den nötigen Teil von dem Platter lesen müsste, da wäre die Zugriffszeit ja nochmal ungleich höher als bei NAND.

Deshalb glaube ich nicht das WD sowas realisiert hat, sondern behaupte einfach mal, dass die Daten die einem LBA geschrieben werden, auch immer auf dem gleichen physikalischen Sektor landen, ggf. eben erst nachdem sie vorher im OnDisk gestanden haben und dieser geleert worden ist. Dieses Leeren sehe ich nicht als die Verschiebung an auf die mgutt sich bezieht, sondern normalen Teil der Funktion eines Schreibcaches und daher schreibe ich auch OnDisk Cache als CMR Zone um klar zu machen das es eben ein Cache ist.

WD benennt die Dinge anders und verwendet Begriffe wie Garbage Collection was bei SSD etwas anderes beschreibt als das Leeren eines Caches, die SSDs haben ja in Form des Pseudo-SLC Caches i.d.R. auch einen Schreibcache der im Idle geleert wird, aber dies hat wenig mit der Garbage Collection zu tun. Es ist aber normal das Hersteller andere Namen für die gleichen Funktionen vergeben und blumige Beschreibungen abliefern um den Eindruck zu erwecken es wäre bei ihnen etwas ganz besonders. Dabei kochen sie alle nur mit Wasser.

aber der CMR Cache ist doch nicht an der finalen Position?

Nein, natürlich nicht, aber dies ist ja bei jedem Schreibcache so und kein besondere Funktion dieser WD SMR HDDs. Ebenso gehört zu jedem Cache ein Indirection Table, man muss ja wissen welche Daten dort stehen und bei einem Schreibcache wohin sie später zu schreiben sind. Außerdem bei jedem Cache auch welche Daten dort stehen um sie aus dem Cache zu lesen, ohne würde ein Lesecache gar nicht funktionieren und bei einem Schreibcache würde man sonst veraltete Daten lesen, während die aktuellen noch im Schreibcache stehen der bisher nicht zurückgeschrieben wurde. Diese Funktionen beschreibt WD, aber die sind für einen Cache einfach normal und auch zwingend nötig, also nicht erwähnenswert. Das ist so selbstverständlich wie das ein Auto eine Lenkung und Bremsen hat.

Danach wie gesagt einen Haufen Dateien drauf schieben, damit die Testdatei-Schindeln "überschindelt" werden

Was willst du eigentlich genau testen? Die Testdaten werden erst in den OnDisk Cache geschrieben und dann im Idle in den SMR Bereich geschrieben, dazu muss man keine weiteren Dateien schreiben.

Interessant wäre ein Lesetest mit HD Tune nachdem die Platte wie im Alltag gelaufen ist, also Dateien schreiben, zwischendurch auch mal welche Löschen und andere Überschreiben etc. so wie es eben im Alltag passiert und dann zu schauen ob die Kurve bei HD Tune wie üblich aussieht oder plötzlich ganz zackig ausseht, was dann bedeuten würde das sie wirklich niedrige LBAs auf innere Spuren und hohe LBAs auf äußere Spuren gemappt hat, aber dies kann ich mir wegen des Aufwands nicht vorstellen.

 

[mgutt]

Was hat TRIM mit dem Verschieben der Daten aus dem Schreibcache zu tun? NICHTS! Du scheinst die Bedeutung von TRIM nicht zu kennen und es mit dem was WD Garbage Collection nennt zu verwechseln, aber es ist ganz was anderes, übrigens auch bei SSDs und ob WD mit Garbage Collection wirklich das Leeren des OnDisk Caches meint, kann ich auch nicht sagen.

Ja, ich habe mal wieder das falsche Wort benutzt. 🙈 Meine Recherche hat ergeben, dass (Media) Cache Cleaning eine gängige Bezeichnung dafür ist. Also nennen wir den OnDisk Cache jetzt Media Cache und den Prozess des Verschiebens Cache Cleaning, ok? ^^

Blöd ist halt, dass wir nicht wissen wann das Cache Cleaning startet und wann es endet.

Mein ihr, dass falls die fio-Testdatei auf der obersten Spur der SMR-Zone liegt, dass der Media Cache dann noch genutzt wird? Weil ich kann mir nicht vorstellen, dass die oberste SMR-Spur langsamer ist als eine normale CMR-Spur.

Ergänzung (3. Juni 2020)

Was willst du eigentlich genau testen? Die Testdaten werden erst in den OnDisk Cache geschrieben und dann im Idle in den SMR Bereich geschrieben, dazu muss man keine weiteren Dateien schreiben.

Für meine erste Annahme, dass die sequentiellen Lesezugriffe einbrechen werden, wäre das tatsächlich nicht notwendig. Schafft man es aber mit den Random Writes den Media Cache zu fluten, wäre der Controller gezwungen das Cache Cleaning auszuführen und das Ziel wäre eine SMR-Zone die mehrere Spuren umfasst und damit würde zusätzlich ein umfangreicher "read-modify-write cycle" ausgelöst, der die Random Writes massiv einbrechen lässt. Eventuell geht es auch ohne die weiteren Dateien, aber das setzt voraus, dass die oberste SMR-Spur (deutlich) langsamer ist als die CMR Spur (Media Cache). und da glaube ich nicht dran, weil schon mehrere Besitzer von SMR Festplatten gesagt haben, dass bei ihnen die Übertragung auch bei großen Datenmengen nicht einbrechen würde. Ich denke die unterschiedlichen Erfahrungen in diesem Punkt liegen an der noch nicht ausgeführten Garbage Collection. Nur an die glaubst du ja nicht, weil du nicht davon ausgehst, dass die Daten in andere SMR-Zonen geschrieben werden, was ich ja glaube.

Ergänzung (3. Juni 2020)

Wo kommt denn das Bild her? Über 300MB/s sind natürlich Quatsch, keine 3.5" HDD schafft so hohe Transferraten und schon gleich gar keine mit nur 5400rpm.

Von Hardwareluxx und den Test hat er wohl mehrfach wiederholt, aber nicht in den Vergleich aufgenommen, weil er sie ebenfalls für unrealistisch hält (nach unten scrollen und dann bei der 6TB Red auf die Galerie gehen):
https://www.hardwareluxx.de/index.p...erschiedener-hersteller-im-test.html?start=10

Er wollte von WD auch eine Erklärung dazu, aber die haben ihm eine Stellungnahme verweigert ^^

 

[fuyuhasugu]

Wenn SMR bei Raid so problematisch ist, dann hätte es doch direkt nach Marktstart erstmals auffallen müssen. Für mich klingt das alles nach typischer Ami-Masche: Man hat einen Fehler gefunden, der bei vielen wahrscheinlich nicht mal auffällt und trotzdem will man jetzt Kapital rausschlagen.

Nein! Erst informieren dann diskutieren. Danke!

Ergänzung (3. Juni 2020)

Es ist doch vollkommen Banane, was für eine technik sie einsetzen. Solange sie keine spezielle Technik beworben und eine andere verwendet haben, kann man ihnen auch ncihts vorwerfen.
Wenn ich als Kunde eine Platte mit einer bestimmten Aufzeichnungstechnologie haben will, dann hätte ich mich vorher darüber informieren müssen und hätte das nicht einfach nur annehmen müssen.

Noch so einer! Siehe oben.

 

[Crass Spektakel]

100GB CMR Cache

Also ich glaube es ist eher weniger, aber ich habe keine 2.5" mit 5TB um es zu prüfen.

Ja, stimmt, bei kleineren Laufwerken sind es deutlich weniger.

Eigentlich ganz witzig sind Host-Managed SMR-Laufwerke. Da kann man teilweise die Aufteilung CMR/SMR extern mit einem Tool einstellen oder beide Bereiche als getrennte Blockdevices ansprechen. Nichts spricht z.B. dagegen die äusseren 25% der Spuren mit CMR und die inneren Spuren mit SMR zu formatieren. Z.B. kann man so eine 8TB-Platte mit 2TB CMR und 8TB SMR verwenden. Eine 10TB-Platte für den Preis einer 8TB-Platte die erst nach 2TB Dauerschreiblast langsam wird ist absolut akzeptabel.

Aber genau das wird dem Endkunden ja nicht angeboten.

Stattdessen bekommen wir 8TB SMR-Platten mit 80GB CMR-Cache der nach fünf Minuten Dauerschreiblast erstmal stundenlang leergeschrieben werden muß und das zu Preisen die praktisch identisch zu einer 8TB CMR Platte sind.

Der Kunde ist ja doof, der merkt das nicht.

 

[Holt]

Blöd ist halt, dass wir nicht wissen wann das Cache Cleaning startet und wann es endet.

Man kann es allenfalls anhand der Zugriffe hören, aber normalerweise passiert dies sobald die HDD wieder Idle ist damit der Media Cache so schnell wie möglich wieder verfügbar ist, sollten wieder Daten geschrieben werden.

Mein ihr, dass falls die fio-Testdatei auf der obersten Spur der SMR-Zone liegt, dass der Media Cache dann noch genutzt wird?

Definiere was Du unter der obersten Spur verstehst! Ich nehmen mal an, dass es die letzte der Spuren einer Zone ist, also die einzige die keine weitere Spur mehr überlappt und daher muss dann auch nichts gelesen und wieder zurückgeschrieben werden, wenn man sie beschreibt. Lass sie uns die letzte Spur einer SMR Zone nennen, die dürfte in der Tat so schnell beschreibbar sein wie der Media Cache, wobei es eine gute Frage ist ob Daten die dort landen vorher auch im Media Cache landen, aber ich vermute schon, zumindest wenn auch Daten im Media Cache stehen die auf einer der anderen Spuren der gleichen SMR Zone kommen, denn dann müsste man diese Daten ja auch womöglich auch wieder lesen und danach zurückschreiben.

Schafft man es aber mit den Random Writes den Media Cache zu fluten, wäre der Controller gezwungen das Cache Cleaning auszuführen und das Ziel wäre eine SMR-Zone die mehrere Spuren umfasst und damit würde zusätzlich ein umfangreicher "read-modify-write cycle" ausgelöst, der die Random Writes massiv einbrechen lässt.

Nein, der Controller wird dann keine Cacke Cleaning ausführen, sondern einfach direkt in den SMR Bereich schreiben, was wegen der "read-modify-write cycle" bei fast allen außer der letzten Spur der SMR Zone führt.

Eventuell geht es auch ohne die weiteren Dateien, aber das setzt voraus, dass die oberste SMR-Spur (deutlich) langsamer ist als die CMR Spur (Media Cache). und da glaube ich nicht dran, weil schon mehrere Besitzer von SMR Festplatten gesagt haben, dass bei ihnen die Übertragung auch bei großen Datenmengen nicht einbrechen würde.

Bei zufälligen Schreibzugriffen werden diese aber eben auf auf Sektoren treffen die nichts auf eben dieser letzten Spur liegen.

Er wollte von WD auch eine Erklärung dazu, aber die haben ihm eine Stellungnahme verweigert

Die einzige Erklärung ist das die Platte wie bei SSDs üblich, weiß wo gültige Daten stehen und bei einer leeren Platten dann einfach keine Daten von der Platte liest, sondern z.B. nur Nullen zurückgibt. Man müsste die neue Platte z.B. zu einem Drittel oder zur Hälfte füllen, dann mit HD Tune benchen und schauen ob sich bis zu diesem Drittel die oder der Hälfte (bei NTFS in der Mitten den per Default 12,5% der Kapazität großen für den MFT reservierten Bereich anlegt) normal verläuft und dann wieder die absurd hohen Werte ausgibt.

 

[Crass Spektakel]

Schafft man es aber mit den Random Writes den Media Cache zu fluten, wäre der Controller gezwungen das Cache Cleaning auszuführen und das Ziel wäre eine SMR-Zone die mehrere Spuren umfasst und damit würde zusätzlich ein umfangreicher "read-modify-write cycle" ausgelöst, der die Random Writes massiv einbrechen lässt. Eventuell geht es auch ohne die weiteren Dateien, aber das setzt voraus, dass die oberste SMR-Spur (deutlich) langsamer ist als die CMR Spur (Media Cache). und da glaube ich nicht dran, weil schon mehrere Besitzer von SMR Festplatten gesagt haben, dass bei ihnen die Übertragung auch bei großen Datenmengen nicht einbrechen würde. Ich denke die unterschiedlichen Erfahrungen in diesem Punkt liegen an der noch nicht ausgeführten Garbage Collection. Nur an die glaubst du ja nicht, weil du nicht davon ausgehst, dass die Daten in andere SMR-Zonen geschrieben werden, was ich ja glaube.

Jein. SMR ist ein voll virtuelles Mapping. In einer SMR-Zonne können theoretisch Sektor 0, Sektor 100 und Sektor 47111234 nebeneinander lieben. Was natürlich beim späteren Lesen Probleme durch massive Headseeks machen kann.

Was ich bei Seagate mal provoziert habe: Wenn sehr viele Random-Seeks den CMR-Cache aus dem Ruder laufen lassen dann wird der anscheinend im Stück in den SMR-Bereich verschoben und erst später intern defragmentiert. Das geht allerdings noch viel langsamer als das normale Ausschreiben den CMR-Caches. Bei mir brauchte eine komplett mit Random-Writes versaute 4TB-SMR-Platte geschlagene 11 Tage (!!!) in denen sie permanent klapperte und Daten rumschob. Aber immerhin, am Ende war sie wirklich fertig. Ein kurzer Gegentest mit Secure-Erase analog einer SSD ergab beim zweiten Test daß es sich wirklich um eine interne Aufräumaktion handelte die sofort beendet wurde wenn alle Sektoren getrimmt wurden.

Ich bin mir ziemlich sicher daß dieses massive rumgeschiebe und Kopfbewegungen deutlich die Alterung des Laufwerkes beschleunigen. Im Prinzip wird aus einer Kopfbewegung grundsätzlich immer drei bis acht Kopfbewegungen.

Noch ein Problem: Klassisches Defragmentieren hilft bei SMR-Platten meistens nicht. Viele Defragmentierer lehnen es ab Laufwerke mit TRIM zu defragmentieren. Aus welchen Gründen auch immer. Diejenigen die es doch tun erzielen oft lausige Ergebnisse da das Mapping intern eben komplett anders sein kann. Teilweise arbeitet die interne Organisation sogar "gegen" das externe Defragmentieren. Noch ein Grund warum SMR oft langsamer ist.

 

[Holt]

SMR ist ein voll virtuelles Mapping. In einer SMR-Zonne können theoretisch Sektor 0, Sektor 100 und Sektor 47111234 nebeneinander lieben.

Das halte ich für ein Gerücht und denke was WD in der Hinsicht beschreibt, bezieht sich alleine auf den Media Cache, daher "defragmentiert" da intern auch nichts intern.

Bei mir brauchte eine komplett mit Random-Writes versaute 4TB-SMR-Platte geschlagene 11 Tage (!!!) in denen sie permanent klapperte und Daten rumschob.

Klar, nachdem der Media Cache voll ist, muss ja auch direkt in den SMR Bereich geschrieben werden, was eben read-modify-rewrite bedeutet, also extrem langsam ist. Es belegt aber nicht das ein Mapping vorhanden wäre, wäre dem so, wäre es ja viel schneller, weil man dann einfach die Sektoren in der SMR Zone von der ersten bis zu letzten beschreiben könnte und sich damit das Lesen und Zurückschreiben sparen könnte, damit würde es so schnell wie bei einer CMR Platte gehen, tut es aber nicht!

 

[mgutt]

Man müsste die neue Platte z.B. zu einem Drittel oder zur Hälfte füllen, dann mit HD Tune benchen und schauen ob sich bis zu diesem Drittel die oder der Hälfte (bei NTFS in der Mitten den per Default 12,5% der Kapazität großen für den MFT reservierten Bereich anlegt) normal verläuft und dann wieder die absurd hohen Werte ausgibt.

Das werde ich dann auch testen. Die EFAX kommt morgen.

 

[Holt]

Achte darauf keine zu alte Version von HD Tune zu nehmen, die älteren, nicht nur die 2.55er, unterstützt nur maximal 2TiB und benchen daher nur den Anfang des Adressbreichs einer größeren HDD. Siehe auch hier und das folgende Post!

 

[mgutt]

Nein, der Controller wird dann keine Cacke Cleaning ausführen, sondern einfach direkt in den SMR Bereich schreiben, was wegen der "read-modify-write cycle" bei fast allen außer der letzten Spur der SMR Zone führt.

Ok, sagen wir er macht das wie gehabt erst beim nächsten Leerlauf. Dann müssen wir aber zumindest dafür sorgen, dass der Cycle aufwendig wird. Und das wird er ja nur, wenn die Testdaten von anderen Schindeln verdeckt sind.

Ergänzung (3. Juni 2020)

Achte darauf keine zu alte Version von HD Tune zu nehmen

Ich habe die aktuellste Pro wegen dem Seagate Lesertest gekauft

Ergänzung (3. Juni 2020)

Ich bin mir ziemlich sicher daß dieses massive rumgeschiebe und Kopfbewegungen deutlich die Alterung des Laufwerkes beschleunigen. Im Prinzip wird aus einer Kopfbewegung grundsätzlich immer drei bis acht Kopfbewegungen.

Klar. Muss ja. Wie viele Bewegungen es sind, wissen wir zwar nicht, weil wir nicht wissen aus wie vielen Spuren eine SMR Zone besteht, aber wenige sind es bestimmt nicht. Deswegen auch meine Aussage zum erhöhten Stromverbrauch. Zwischen Lesen/Schreiben, Betrieb und Leerlauf (Kopf geparkt) liegen je nach Modell 4W und die spart die CMR Platte durchgehend, während die SMR arbeitet und arbeitet.

Wenn ich den Test mache, dann werde ich 3TB auf die Platte schreiben und 1TB an Daten wieder löschen. Dann warte ich solange bis die Platte Ruhe gibt. Mal sehen wie lange das dauert und wie viel Strom in Summe die CMR dafür verbraucht hat und wie viel die SMR.

 

[DarkSoul]

Nein! Erst informieren dann diskutieren. Danke!

Blödsinn, richtig lesen und dann einen Gegenbeweis liefern. Ansonsten kannst Du auf Kommentare verzichten, Danke!

 

[fuyuhasugu]

Blödsinn, richtig lesen und dann einen Gegenbeweis liefern.

Du forderst einen Gegen_Beweis_ zu einer hinsichtlich des Artikelinhalts substanzlosen Behauptung a la „hätte“ und „klingt nach“? Sorry, so tief tauche ich auch im CB-Forum nicht.

BL+1

 

[DarkSoul]

Du forderst einen Gegen_Beweis_ zu einer hinsichtlich des Artikelinhalts substanzlosen Behauptung a la „hätte“ und „klingt nach“? Sorry, so tief tauche ich auch im CB-Forum nicht.

So schwer kann es ja nicht sein einen Test z. B. zu einer WD Red EFAX zu finden, die das Problem zeitnah aufzeigt, oder etwa doch? Also Link oder fang den Fisch, meine Ignoreliste mag Trolle gerne.

 

[mgutt]

Eine 10TB-Platte für den Preis einer 8TB-Platte die erst nach 2TB Dauerschreiblast langsam wird ist absolut akzeptabel.

Das mit dem Preis hatte ich auch schon angesprochen. Wenn die Red SMR als zB "Red Lite" mit deutlichem Preisnachlass angeboten worden wäre, hätte sich ja keiner beschwert. Dann weiß man ja worauf man sich einlässt. Aber aktuell sieht es ja danach aus als wollten die Hersteller die SMR einfach zum selben Preis wie die CMR verkaufen.

Ob eine große CMR Zone (viel) mehr bringt bezweifle ich allerdings. Wenn du eine große Datei sequentiell auf die SMR Zone schreibst, dann ist die SMR genauso schnell beim Lesen und Schreiben wie die CMR. Die CMR Zone, also der Media Cache soll dagegen "nur" die Random Writes auf bereits bestehende SMR-Zonen abfangen. Damit sind die Writes so lange schnell, solange der Media Cache noch nicht voll ist. Wenn du den vergrößerst, kannst du natürlich mehr Random Writes abdecken. Nur das hilft dir bei einem Problem wie dem ZFS Rebuild nicht, weil der alle Sektoren betrifft und die Größe des Media Cache beeinflusst ja die nutzbare Größe. Und damit die Platte möglichst günstig sein kann, müssen ja möglichst wenig Platter verbaut werden. Also die Frage: Willst du mehr Random Writes oder mehr Speicherplatz? Genau diese Entscheidung wird bei den HM-SMR Platten dem Nutzer überlassen, aber der überlegt sich auch 2x ob er einen Großteil des Speicherplatzes für CMR Spuren opfern will.

 

[Holt]

Ok, sagen wir er macht das wie gehabt erst beim nächsten Leerlauf. Dann müssen wir aber zumindest dafür sorgen, dass der Cycle aufwendig wird. Und das wird er ja nur, wenn die Testdaten von anderen Schindeln verdeckt sind.

Was soll der Controller denn sonst machen wenn der Media Cache voll ist und trotzdem weiter Daten geschrieben werden sollen? Der kann sich ja nicht eine halbe Stunde Pause gönnen um Media Cache zu cleanen. Der Type aus dem Link von dir hatte von maximal 3 Minuten berichtet, das reicht bei weitem nicht zu cleanen des Media Cache aus. Wäre die Red Host Aware, könnte man die Geometrie auslesen (frag mich aber nicht wie, ich habe mich nie befasst), aber die Red sind es meines Wissens nach nicht. Aber das ist auch egal, bei wirklich zufälligen Schreibzugriffen landen die Daten ja auch zufällig auf allen Spuren, mal auf einer die kleine anderen Spuren überdeckt, aber je nachdem wie viele Spuren sich überdenken, meistens auf einer die eine andere überdeckt. Da wäre es interessant ob der Controller dann weiß ob die überdeckte Spur schon gültige Date enthält oder nicht, denn wenn da keine günstigen Daten drauf stehen, könnte er sich das Lesen und Zurückschreiben ja auch sparen. Den Test sollte man also ggf. einmal mit neuer, leerer (bzw. gerimmter) HDDs ausführen und danach die Platten komplett mit Daten füllen und wiederholen. Gibt es einen deutlich Unterschied, so weiß der Controller also wo gültige Daten stehen.

Klar. Muss ja.

Wieso muss es? Es gibt mehr Kopfbewegungen, keine Frage, aber die Mechanik könnte auch darauf ausgelegt sein viel mehr Kopfbewegungen zu überleben. Das die Kosten pro Platter mit SMR offenbar höher als für Platter ohne SMR sind, hatte wir ja schon mal besprochen.

mit deutlichem Preisnachlass angeboten worden wäre

Der scheint nicht möglich zu sein, daher glaube ich auch nicht, dass man eine SMR HDD mit 8TB SMR und 2TB CMR Bereich, wenn der wie von Crass Spektakel bei Host-Managed SMR-Laufwerken wählbar und im Verhältnis 1:4 (CMR zu SMR Kapazität) liegt, wäre dies eine 16TB SMR HDD, die niemals zum Preis einer 8TB oder auch 10TB ohne SMR zu haben sein wird. Aber wie gesagt, mit den Host-Managed SMR habe ich mich nie groß beschäftigt und nur im Hinterkopf behalten, dass man diese nicht wahlfrei beschreiben kann, sondern immer komplette SMR Zonen überschreiben muss, will man da also nur einen Sektor ändern, muss man die ganzen Daten der SMR Zone lesen und komplett wieder zurückschreiben. Damit sind sie sicher nicht schneller als die Device Managed, aber der Host dies selbst aktiv machen und wartet daher nicht so lange auf eine Antwort der Platte.

 

[mgutt]

Das Hass-Objekt ist da ^^

Ich muss jetzt aber erstmal den Lesertest weiter machen. Ich denke erst nächste Woche kommen dann die Testergebnisse.

Was ich aber schon mal sagen kann: Man ist die leicht. Wie leicht musst da erst die 2TB Version sein ^^

 

[deo]

Man ist die leicht.

Bei SSDs wird auch immer weniger Material für mehr Speicherkapazität benötigt, vor allem die im 2,5" Gehäuse, wo der Platz immer weniger gebraucht wird, wenn die Kapazität nicht stark erhöht wird.
Die Samsung SSD830 mit 128GB wiegt 59g. Da war der Platz im 2,5" Gehäuse noch von der Platine genutzt. Aktuell kommt eine 4TB 860Evo auf 62g. Das Gewicht ist nahezu gleich geblieben bei 32facher Kapazitätssteigerung.
Da haben Festplatten noch einiges vor, wobei die im Laufe der Jahrzehnte auch immer leichter wurden.



Bei Geizhals steht jetzt bei Festplatten ein mit wichtig gekennzeichneter Hinweistext, der auf die Problematik von SMR im RAID hinweist.
Die haben das wohl zum eigenen Schutz vor negativen Bewertungen gemacht. Man kann da also wissen, was man bekommt, bevor man es kauft.

Wichtig Zur Verwendung innerhalb eines RAID-Verbunds, sollten keine Festplatten mit unterschiedlichen Aufzeichnungsverfahren (CMR, SMR) kombiniert werden. Bei Verwendung von Festplatten mit SMR in einem RAID-Verbund, ist darauf zu achten, dass der RAID-Controller (bzw. das NAS-System) zu SMR-Festplatten kompatibel ist, um das teilweise geblockte Aufzeichnungsverhalten beim SMR nicht fälschlich als "Hardware-Defekt" zu deuten.