Du verwendest einen veralteten Browser. Es ist möglich, dass diese oder andere Websites nicht korrekt angezeigt werden. Du solltest ein Upgrade durchführen oder einen alternativen Browser verwenden.
NewsWestern Digital: Sammelklage wegen heimlichen SMR-Festplatten
Doch macht sie wohl!
Warum nur ist mein Beispiel so unverständlich?
das |XYZ| bezeichnet doch keine Spur, sondern einfach nur einen SMR Abschnitt der doch schon über mehrere Spuren geht.
Dass der ganze Abschnitt geschrieben werden muss um ein einzelnes Element darin zu ändern sollte doch deutlich genug sein möchte man meinen.
Wenn es hilft dann betrachte man jeden Buchstaben innerhalb der | als einzelne Spur, auch wenn es keine Rolle spielt wie groß genau diese einzelnen Datenteile sind.
Solange es von dir keine konkreten Antworten gibt, warum solltest du die bekommen?
Mal abgesehen davon dass die Bezeichnung und weitere von dir aufgezählt Features gar nichts bringen wenn eine grundlegende Eigenschaft - die nicht erwähnt wird - absolut unpassend ist...
Nach 1,5TB ist die SMR Platte jetzt mal richtig schön langsam.
Bei meinen Tests mit SSDs, also von SSD lesen auf SMR HDD schreiben, hatte ich das aber nicht, obwohl das auch haufenweiße kleine Dateien waren. Kann es sein das hier die Lesegeschwindigkeit der Quell (SMR) HDD Limitiert?
Sehe ich auch so deshalb habe ich die SMR HDDs ja, wenn ich Speed brauche nehme ich NVMe SSDs (Samsung 970 Evo Plus), wenn das für den Vorgesehenen Zweck zu teuer ist Sata SSDs mit TLC (Samsung 860 Evo), Wenn Speed fast egal ist mit QLC (Samsung QVO oder Micron 5210 ION) und für Backups dann SMR HDDs (LaCie 5TB Mobile HDD)
Hä, sagt mal geht's noch?
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.
Der Hersteller garantiert mit nur eine bestimmte Kapazität, Geschwindigkeit, Haltbarkeit und sonst nichts und wenn ich eine Platte mit diesen Parametern kaufe, dann ist es doch wohl dem Hersteller überlassen, wie er das umsetzt.
Jetzt kann man ihn doch nicht dafür verklagen, weil er das anders macht als man es gedacht hat.
zwar werden sie unterschiedliche Generationen von Platter fertigen, wenn man einen neuen mit mehr Datendichte hat, stellt man die Fertigung ja nicht über Nacht nur noch auf diesen um, aber es gibt ja immer auch Fehler auf der Oberfläche und die nutzbare Kapazität ist dann geringer als bei einem Platter mit wenig oder gar ganz ohne Fehler, weshalb man dann solche mit mehr Oberflächenfehlern in Platten verbaut, wo man gar nicht die ganze Kapazität brauchen würde. So wurde es von WD auch schon mal am Beispiel der 3TB Blue beschrieben
Ja aber dann müssten die WD60EFRX ja quasi jedes Jahr ein anderes Gewicht im Datenblatt besitzen, weil dann irgendwann durch eine Revision weniger Platter verbaut wurden. Ich habe mal gesucht, aber wirklich finden tue ich dazu nichts. Also ob es die auch mal mit 4 Platter gab, statt den 5 Plattern bei Release. Oder meinst du die hatten immer 5 Platter, nur eben eigentlich größere, die dann eben mehr ungenutzte Bereiche hatten? Selbst dann müsste sich ja eigentlich maßgeblich was ändern. Entweder im inneren oder äußeren Bereich wegen der Geschwindigkeit oder der Stromverbrauch, weil andere Schreib/Leseköpfe verbaut werden mussten usw. Das dürfte ja nicht gerade trivial sein was man durch eine solche Revision auslöst. Ich kann ja mal wiegen. Ich hab WD60EFRX von 2015 bis 2016 da ^^
Hä, sagt mal geht's noch?
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.
Der Hersteller garantiert mit nur eine bestimmte Kapazität, Geschwindigkeit, Haltbarkeit und sonst nichts und wenn ich eine Platte mit diesen Parametern kaufe, dann ist es doch wohl dem Hersteller überlassen, wie er das umsetzt.
Jetzt kann man ihn doch nicht dafür verklagen, weil er das anders macht als man es gedacht hat.
Das mag bei Privatanwendern, die nur eine Platte allein betreiben, zutreffen. Jedoch ist glaube ich ganz eindeutig unbestritten, dass die SMR-Technik genau in dem Bereich, für den die betroffenen Platten beworben werden, baulich bedingte entscheidende Nachteile mit sich bringen. Meinem Laienverständnis nach könnte es sich hier (nach deutschem Recht) sehr wohl um einen versteckten Mangel handeln, denn ich denke, dass niemand ernsthaft behaupten möchte, neun Tage für den Rebuild eines RAID-Arrays seien angemessen.
Und hier seien die Fälle von Platten, die ebenda von diversen Controllern als offensichtlich defekt ausgeworfen werden, nur am Rande erwähnt.
Der Hersteller garantiert mit nur eine bestimmte Kapazität, Geschwindigkeit, Haltbarkeit und sonst nichts und wenn ich eine Platte mit diesen Parametern kaufe, dann ist es doch wohl dem Hersteller überlassen, wie er das umsetzt.
Ich stimme ihnen grundsätzlich zu (siehe oben) aber WD wirbt damit wie Toll die Platte für RAID ist, wärend die Platte Tage(!) für den Rebuild braucht und ihn teils mit seltsamen Fehlern abbricht.
Die Daten stehen hinterher auch nicht woanders, sondern wieder genau da wo sie vorher standen, im SMR Bereich gibt es kein Remapping (außer bei Defekt auf Reservesektoren), dies gibt es nur im OnDisk Cache wo die Daten eben nur temporär stehen.
Natürlich lässt die Erklärung aus dem WD Blog Artikel noch was Spielraum, aber sie schreiben ja zu Anfang, dass die Daten zerstört würden, wenn man unten liegende Schindeln einfach überschreiben würde (das meinte ich mit "kann nicht beschrieben werden"):
However, using this architecture, data from the “down shingle” track will be erased when writing, thus making laying down new data to a previously written location impossible without destroying old data from the down shingle track
Dieses umfasst die Defragmentierung dieser auf dem Datenträger schlussendlich stark verstreuten LBA Gruppen:
Data storage devices, such as disk drives using shingled recording media and solid state drives, can use “logical block address (LBA) indirection” to store user data on non-volatile media, such as a disk surface or flash memory, wherein LBAs and associated data are not typically stored in the same physical location each time they are written. In a data storage device using LBA indirection, a host may write a logically sequential group of LBAs into a corresponding number of sequential physical locations on the non-volatile media. However, as the LBAs are rewritten by the host, they may end up in non-sequential physical locations. Thus, a group of LBAs that was once sequentially written onto the non-volatile media may become scattered at different locations on the media as they are rewritten. As a result, the non-volatile media will become increasingly fragmented over time, which can significantly degrade the read performance of the data storage device.
In addition, a data storage device that uses LBA indirection typically uses a translation table to keep track of LBAs and corresponding physical locations on the non-volatile media. As the non-volatile media becomes fragmented, the number of entries in the translation table increases, thereby undesirably increasing the amount of memory required to store the translation table.
To overcome the aforementioned problems associated with fragmentation of the non-volatile media, a defragmentation may be employed. In a defragmentation process, a range of LBAs may be selected, read from the non-volatile media (e.g., a shingled recording media), and rewritten as a sequential stream onto the non-volatile media. The above steps may be repeated for each LBA range on the non-volatile media. This process increases read performance of the non-volatile media and also reduces the size and required storage space of the translation table. However, the defragmentation process can be an expensive operation in that it can increase latency and reduce overall data storage device performance. Thus, it is important to perform the defragmentation process efficiently so as to minimize the aforementioned undesirable effects.
Und genau das sind die Aufräumarbeiten, die DMSMR immer dann macht, wenn sich das Laufwerk im Leerlauf befindet. So verstehe ich das zumindest.
Ergänzung ()
AlphaKaninchen schrieb:
Nach 1,5TB ist die SMR Platte jetzt mal richtig schön langsam.
Anhang anzeigen 927200
Bei meinen Tests mit SSDs, also von SSD lesen auf SMR HDD schreiben, hatte ich das aber nicht, obwohl das auch haufenweiße kleine Dateien waren. Kann es sein das hier die Lesegeschwindigkeit der Quell (SMR) HDD Limitiert?
Ich kopiere die Datein von mehreren kleinen Platten auf eine Große um sie einfacher Sortieren zu können da wäre zip contraproduktiv, so muss ich halt etwas warten, ich habe es eigentlich nur geposstet weil es das erste mal war, dass das kopieren auf die HDD richtig langsam wurde.
Ich kopiere die Datein von mehreren kleinen Platten auf eine Große um sie einfacher Sortieren zu können da wäre zip contraproduktiv, so muss ich halt etwas warten, ich habe es eigentlich nur geposstet weil es das erste mal war, dass das kopieren auf die HDD richtig langsam wurde.
Ich meinte jetzt auch nur zum Test, damit man sieht, dass es nicht an den vielen kleinen Dateien liegt. Waren es denn bei früheren Kopiervorgängen auch so viele kleine Dateien?
Ich meinte jetzt auch nur zum Test, damit man sieht, dass es nicht an den vielen kleinen Dateien liegt. Waren es denn bei früheren Kopiervorgängen auch so viele kleine Dateien?
Sehr unterschiedlich, auf einer der Platten waren TV Aufnahmen auf der nächsten VollBackups von PCs etc, kopiert habe ich dabei von HDDs und SSDs (zwei HDDs wollten sich nicht gleichzeitig am PC anmelden, daher über denn umweg der internen SSD) Bei denn HDDs waren es immer zwischen 30 und 130 Mbit/s je nach füllstand und größe der Dateien, bei der SSD nie unter 80 Mbit/s
Wenn ich fertig bin werde ich dann wirklich mal Testen hab nämlich noch eine fast leere von den 5TB 2,5" HDDs...
Ich habe wieder was Interessantes gefunden. WD hat im Juni 2018 noch gesagt, dass DM-SMR Festplatten nur für Anwendungen sinnvoll sind wo genug Leerlaufzeit gegeben ist. Also wie bei einem Desktop PC oder einer externen Festplatte. Aber für parallel laufende Operationen wie Backups seien sie wegen der Performance-Probleme "unangemessen": https://documents.westerndigital.co...d-magnetic-recording-helioseal-technology.pdf
Drive Managed SMR is suitable for applications that have idle time for the drive to perform background tasks such as moving the data around. Examples of appropriate applications include client PC use and external backup HDDs in the client space. In the enterprise space, parallel operations of backup tasks become random write operations within the HDD, which typically result in unpredictable performance or significant performance degradation.
Da steht zwar nicht explizit NAS, aber ein NAS ist auch keine externe Festplatte, wo in der Regel nur ein Nutzer drauf zugreift (bei 5 bis 8-Bays noch unwahrscheinlicher). Solche Formulierungen könnten sich im Gerichtsverfahren als Eigentor herausstellen. Für Enterprise wird dagegen ganz klar "unpraktisch" und "nicht akzeptabel" gesagt:
Because the HDD constantly works to optimize the caching algorithm and indirection table handling, performance is unpredictable at certain workloads such as large block random write with high duty cycles. Due to the wide range of performance variability and unpredictability, Drive Managed SMR is considered impractical and unacceptable for enterprise-class deployments.
Und das "constantly works to optimize the caching algorithm and indirection table handling" ist genau der Grund warum die WD60EFAX mehr Strom verbraucht als die WD60EFRX.
Eine 5TB Datei gefüllt mit zufälligen Daten oder meinst du wirklich 5TB Random Writes, also 4KB kleine Dateien, die per Zufall auf die Festplatte geschrieben werden?! Bei CrystalDiskMark wird ja dafür erstmal eine zB 64GiB große Datei auf die Festplatte geschrieben und gezielt auf die Sektoren dieser Datei per Zufall erneut geschrieben. Ein Tool, das mehr als 64 GiB kann, kenne ich nicht (der Vorgang würde ja auch ewig dauern).
Wenn es dir aber nur um eine Datei mit zufälligem Inhalt geht, kannst du dir ja hier die 1TB Testdatei runterladen: http://speedtest.tele2.net/
Eine 5TB Datei gefüllt mit zufälligen Daten oder meinst du wirklich 5TB Random Writes, also 4KB kleine Dateien, die per Zufall auf die Festplatte geschrieben werden?! Bei CrystalDiskMark wird ja dafür erstmal eine zB 64GiB große Datei auf die Festplatte geschrieben und gezielt auf die Sektoren dieser Datei per Zufall erneut geschrieben. Ein Tool, das mehr als 64 GiB kann, kenne ich nicht (der Vorgang würde ja auch ewig dauern).
Ich meinte 4KB kleine Datein Zufällig ich möchte wissen wieviel CMR die HDD hat / wann sie einbricht... Bei Sequentiellem Schreiben fällt dies ja nicht so sehr auf.
Durch den SMR statt CMR Skandal habe ich diesmal auch zu Seagate gegriffen, zumindest bei deren IronWolf HDDs soll wohl noch CMR zum Einsatz kommen. Mal sehen wie Lange die halten (meine alte WD läuft immer noch ohne Probleme, allerdings habe ich diese nicht im RAID laufen)
Ich meinte 4KB kleine Datein Zufällig ich möchte wissen wieviel CMR die HDD hat / wann sie einbricht... Bei Sequentiellem Schreiben fällt dies ja nicht so sehr auf.
Ich dachte erst, wenn man einfach CrystalDiskMark immer wieder neu startet, aber man produziert damit ja noch lange keine überlappenden Schindeln. Tatsächlich bräuchte man jetzt ein Benchmark-Tool, das eine Datei auf die Platte schreibt, dann pausiert man den Vorgang. Schreibt lustig viele weitere Daten auf die Platte und erst dann startet man den Random-Write.
EDIT: Ich habe eine Idee. Du startest CrystalDiskMark, stellst es 5 Durchläufe und die Größe auf 64 GiB und startest den vollständigen Test (All):
Die Ergebnisse hältst du mit einem Screenshot fest. Danach wiederholst du den Test. Wie zuvor erstellt er erst mal eine Test-Datei auf der Platte:
Das dauert je nach Geschwindigkeit der HDD eine Weile. In der Zeit öffnest du schon mal den Ressourcen-Monitor (Task-Manager -> Leistung -> ganz unten), gehst auf den CPU Tab und suchst den Prozess DiskMark64.exe und per rechte Maustaste wählst du schon mal "Vorgang anhalten":
Es kommt dann erst mal nur der Bestätigungsdialog (die Testdatei wird also weiter geschrieben):
Sobald die Testdatei dann komplett geschrieben wurde drückst du sofort auf "Vorgang anhalten". CDM ist nun eingefroren.
Jetzt heißt es den TRIM ausführen bzw diesen abwarten. Wir wollen damit sicher gehen, dass die Testdatei auf dem Backstore gelandet ist.
Nun schreiben wir haufenweise Dateien auf die Platte. Vielleicht 1TB oder so. Damit wollen wir erreichen, dass die Testdatei auf Schindeln liegt, die durch andere Schindeln verdeckt werden.
Und erst jetzt lassen wir CDM weitermachen. Ich denke dann sollte die Performance zum vorherigen Test einbrechen. Selbst wenn die Platte LBA Indirection unterstützt und sie dadurch die 4K Random Writes in der CMR Zone abfängt, sollten die sequentiellen Lesezugriffe einbrechen, da die Platte dann die, durch die Random Writes geänderten Daten, von der CMR Zone lesen muss und die noch nicht geänderten Daten vom Backstore. Natürlich alles vorausgesetzt, dass ich die SMR-Technik richtig verstanden habe ^^
Das ist es auch, seit die Seagate Archive vor so 5 Jahren auf den Markt gekommen sind, konnte jeder der es wollte dies ausprobieren. Bei den Red kommt aber noch der IDNF Bug dazu, den haben die Seagate HDDs mit SMR nicht und die wurden eben auch nie für den RAID Einsatz beworben.
DarkSoul schrieb:
Die Amis verfolgen ein anderes Ziel: Sie wollen Konkurrenz vom US-Markt drängen, mit allen Mitteln.
Bei meinen Tests mit SSDs, also von SSD lesen auf SMR HDD schreiben, hatte ich das aber nicht, obwohl das auch haufenweiße kleine Dateien waren. Kann es sein das hier die Lesegeschwindigkeit der Quell (SMR) HDD Limitiert?
Da die 12TB erst später angekündigt wurde, sollte es mich nicht wundern wenn man bei den 6TB von 5 Platter dann auf 3 SMR Platter gewechselt ist, statt dann auf 4 ohne SMR mit der Datendichte wie bei der 12TB.
mgutt schrieb:
Du sagst "elsewhere" ist die CMR Zone und wenn dann der TRIM erfolgt, werden die Daten zurück in die ursprüngliche SMR Zone geschrieben.
Nein, wo soll ich das behauptet haben? Ich habe nichts dazu gesagt wo diese Daten zwischengespeichert werden und erst recht nicht, dass sie erst nach einem TRIM wieder zurückgeschrieben werden. Letzteres wäre totaler Schwachsinn, die Daten werden aber sofort wieder zurückgeschrieben, nachdem sie wegen des Schreiben des überlappenden Nachbarsektors überschrieben wurden. Sie nur im DRAM Cache zu halten, wäre wegen des Risikos unerwarteter Spannungsabfälle gefährlich, daher wäre es durchaus anzunehmen, dass sie im OnDisk Cache zwischengespeichert werden.
TRIM hat damit sowieso nur in sofern zu tun, als dass Daten deren LBAs getrimmt wurden, eben nicht mehr vorher gelesen, irgendwo zurückgespeichert und dann zurückgeschrieben werden müssen, da stehen dann eben andere Daten (die der Nachbarspur) drin, aber wirklich etwas für die Performance bringt es natürlich nur, wenn die ganzen LBAs einer Spur oder bessere noch einer SMR Zone getrimmt wurden.
mgutt schrieb:
Dass es einen CMR Cache bei SMR gibt ist nicht neu, was diese Präsentation von 2013 zeigt:
Keine Ahnung ob das für Host Managed SMR Platten so gilt, die alte HGST Ha waren solche Host Managed SMR, aber bei den normalen Device Managed SMR funktioniert dies so garantiert nicht, denn der Host (PC, NAS) sucht hier nicht den unassigned block, dafür gibt es keine entsprechenden Befehle und dies ist so nicht vorgesehen, sondern der Host schickt der Platte den Befehl ab LBA x die folgenden y LBAs zu beschreiben und die muss dann damit umgehen wie und wo sie diese Daten speichert. Was das Patent beschreibt ist ja nicht notwendigerweise was die konkreten Produkte Jahre später auch machen, denn wenn sie es so machen, bräuchten sie wie SSDs einen kompletten indirection table (Mappingtabelle) und die wird groß und deren Verwaltung ist aufwendig, wenn sie nicht komplett im DRAM Cache steht und bei 6TB wäre dafür gut 6GB RAM nötig, bremst sie auch die Lesevorgänge, da ja immer wieder der passende Teil nachgeladen werden muss um zu wissen wo die Daten nun wirklich stehen. Steht ja auch im Patent:
In addition, a data storage device that uses LBA indirection typically uses a translation table to keep track of LBAs and corresponding physical locations on the non-volatile media.
Man würde es übrigens an der Kurve von HD Tune sehen, wenn so ein Mapping erfolgen würden, da ja die äußeren Spuren höhere Transferraten als die inneren haben und wenn nicht mehr die Daten der höheren LBAs auf den weiter innen liegenden Spuren sind, sondern auf einmal auf weiter außen liegenden, würde die Kurve bei HD Tune plötzlich ansteigen. Ich kann mir nicht vorstellen das WD dies so umgesetzt hat, da der Aufwand in kleinem Verhältnis zum Nutzen stehen würde, dieser Nutzen wäre dann weniger Verzögerung beim Schreiben zu haben weil man dann eben Daten dort schreiben kann wo man dafür keine anderen überschreiben muss, die ja eben vorher gelesen und nach zurückgeschrieben werden müssen. Aber die Red zeigt bei Alan Brown bis zu 3 Minuten Verzögerungen. Daher solltest Du diese ganzen Beschreibungen und Patente besser nicht zu ernst nehmen, so könnte man es zwar machen, aber wegen des damit verbundenen Aufwands wird es wohl kaum je so gemacht werden und alle bisherigen Erfahrungen mit der Red zeigen auch, dass sie genau so wie die Seagate SMR HDDs arbeitet, also nichts mit Mappingtabelle und Verschieben von Daten auf andere physikalische Positionen.
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.
Ergänzung ()
mgutt schrieb:
Da steht zwar nicht explizit NAS, aber ein NAS ist auch keine externe Festplatte, wo in der Regel nur ein Nutzer drauf zugreift (bei 5 bis 8-Bays noch unwahrscheinlicher). Solche Formulierungen könnten sich im Gerichtsverfahren als Eigentor herausstellen.
Genau das sind die Anwendungen für einfach Desktopplatten wie die Seagate Barracuda (Compute) oder die WD Blue, diese stecken ja üblicherweise in den USB Gehäuse der USB Platten die man fertig kauft und die werden eben nicht für RAID Anwendungen beworben, die haben ja auch nicht einmal TLER / ERC.
Das Dokument beschreibt ja genau das was die Leute nun feststellen und weshalb es diese Klage gibt. Wenn so ein Dokument bei WD intern und sogar offen im Netz verfügbar war, wieso konnte dann trotzdem jemand entscheiden die Red Baureihe mit SMR zu bringen?
mgutt schrieb:
Jetzt heißt es den TRIM ausführen bzw diesen abwarten.
Durch TRIM wird nichts an Daten verschoben, wäre ja auch totaler Blödsinn sowas zu machen. Das einzige was man damit erreicht ist, dass die Testdaten aus dem OnDisk Cache auf ihre finale Position kopiert werden, nicht mehr und nicht weniger. Man bencht danach beim Lesen als die Daten in ihrem SMR Bereich statt wie sonst im OnDisk Cache der CMR ist, aber es ja überall kleine CMR Bereich die als OnDisk Cache dienen, dies ist nicht ein einzelner Bereich irgendwo, sondern über ein kleiner Bereich um Daten möglichst in der Nähe ihrer finalen Position in den SMR Zone zu speichert, daher sollte es auch keine nennenswerten Unterschiede bei der Leseperformance geben.
Ergänzung ()
mgutt schrieb:
Nun schreiben wir haufenweise Dateien auf die Platte. Vielleicht 1TB oder so. Damit wollen wir erreichen, dass die Testdatei auf Schindeln liegt, die durch andere Schindeln verdeckt werden.
Und erst jetzt lassen wir CDM weitermachen. Ich denke dann sollte die Performance zum vorherigen Test einbrechen
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.
mgutt schrieb:
Selbst wenn die Platte LBA Indirection unterstützt und sie dadurch die 4K Random Writes in der CMR Zone abfängt, sollten die sequentiellen Lesezugriffe einbrechen, da die Platte dann die, durch die Random Writes geänderten Daten, von der CMR Zone lesen muss und die noch nicht geänderten Daten vom Backstore.
Richtig, nur nutzt CDM die Datei nach den Random Writes doch gar nicht mehr für sequentielles Lesen, oder irre ich mich da? Die sequentielle Tests sind doch abgeschlossen, wenn die Random beginnen. Aber ansonsten wäre es schon richtig, wenn man nach dem Schreiben der SMR Platte genug Zeit im Idle lässt um den OnDisk Cache zu leeren, dann Teile der Datei überschreibt, was dann wieder im OnDisk Cache steht und gleich danach, also ohne ihr Zeit zu geben den OnDisk Cache zu leeren, die Datei wieder komplett liest, dann wird dies langsamer sein, weil der Köpfe zwischen der Position der Daten auf dem SMR Bereich und dem OnDisk Cache hin und her bewegt werden müssen.
Eine LBA Indirection für den OnDisk muss die Platten in jedem Fall unterstützen, wie bei jedem Cache stehen dort ja Daten drin zu denen man wissen muss wo sie eigentlich hin gehören und wie bei jedem Cache muss beim Lesen geschaut werden ob die Daten im Cache vorhanden sind (es ist ja ein reiner Schreibcache) und wenn ja, dann müssen sie aus dem OnDisk Cache gelesen werden, ebenso gilt dies ja auch für den DRAM Cache der HDD, die legen dort ja auch Userdaten ab.
mgutt schrieb:
Natürlich alles vorausgesetzt, dass ich die SMR-Technik richtig verstanden habe
Genau das passiert nicht. Sonst wäre der CDM Random nicht so krass gut (für eine HDD):
Entweder landen die Random Writes in der CMR Zone (Write Buffer) oder sie wurden in neue SMR Zonen geschrieben. Aber mit lesen und überschreiben einer Zone schafft man es sicher nicht 10x schneller als eine CMR Platte zu sein.
Ergänzung ()
Holt schrieb:
Man würde es übrigens an der Kurve von HD Tune sehen, wenn so ein Mapping erfolgen würden
Stimmt. Denkfehler. CDM wiederholt ja nicht alle Tests nachdem der letzte durch ist, sondern wiederholt den Teiltest, der gerade läuft. Kann man in CDM den Random-Test vor dem sequentiellen ausführen, dann würde sich das zeigen, wenn meine Vermutung stimmt?
Genau da gehen wir auseinander. Ich denke, dass die Daten mit der Zeit massiv fragmentieren, wenn kein Trim bzw WD sagt ja Garbage Collection ausgeführt wird. Aber das ist auch logisch, weil du ja sagst, dass die Daten einfach komplett überschrieben werden und ich gehe halt vom Schreiben auf neue Zonen aus.
Ich habe mir jetzt einfach mal eine WD60EFAX bestellt. Sag mir was ich testen soll. Dann kommen wir schon dahinter ^^
Ergänzung ()
Holt schrieb:
Durch TRIM wird nichts an Daten verschoben, wäre ja auch totaler Blödsinn sowas zu machen. Das einzige was man damit erreicht ist, dass die Testdaten aus dem OnDisk Cache auf ihre finale Position kopiert werden, nicht mehr und nicht weniger.
Ich kann dir nicht folgen. Erst sagst du, dass TRIM nichts verschiebt und dann sagst du, dass die Testdaten vom OnDisk Cache auf die finale Position kommen. Häh? 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
Ergänzung ()
@AlphaKaninchen
Falls du es so machst wie ich es beschrieben hatte, dann benutz CDM5. Dort kommt noch mal ein sequentieller Test nach dem 4K Random:
