News Western Digital: Sammelklage wegen heimlichen SMR-Festplatten

[Joker*]

Überschrift: wegen heimlicher

 

[jemandanders]

Seit wann schrecken hohe Strafen eine Firma ab, böses zu tun?

Ich denke mal, VW wird da in Zukunft etwas vorsichtiger sein. Vermutlich.

naja nicht ganz siehe Intel mehre Milliarden strafen bekommen, hat Sie wenig interessiert siehe Matlab z.b. (Intel compiler).

Die eine Milliarde an AMD?
Dass war doch Portokasse. Gegen die EU Strafe läuft die Berufung sogar immer noch.

Keine Hersteller kann Sicherheitslücken ausschließen, aber keiner baut die mit Absicht ein

Jein.
Intel hatte SMT schon zu Prescott Zeiten im Einsatz. Damals wurden die ersten Seitenkanalangriffe gefahren.
Bei den ersten Core CPUs haben sie es dann weg gelassen.
Als AMDs Bulldozer als unbekannte Größe quasi als Damoklesschwert über ihnen schwebte, haben sie die gleiche Technik inkl. alle Fehler sehenden Auges wieder eingebaut. Weil -Leistung ist wichtiger gewesen.
Die Fehler selbst nehme ich denen noch nicht einmal richtig Übel. War halt Schlampigkeit.
Das sie das ganze aber bewusst wieder eingebaut haben schon.

 

[mgutt]

, aber davor was nicht absehbar dass sich der Preis groß ändern würde.
dieses Plateu von mitte 2016 bis mitte 2017
da ich aber keine funktionierende Glaskugel habe passiert sowas eben.

Damit meinte ich keine steigenden oder fallenden Preise, sondern nur den Preisunterschied zwischen CMR und SMR. CMR gab es zu dem Zeitpunkt für um die 200 € (also ähnlich teuer wie die Seagate Archive SMR):

https://www.mydealz.de/deals/wd-my-...-usb-30-ausbaubar-fur-19856-amazoncouk-781389

https://www.mydealz.de/deals/8-tb-western-digital-wd80ezzx-red-ahnlich-platte-fur-nas-upgrade-902834

Die günstigen 8TB Red gab es glaube ich erst ab Ende 2017:
https://www.mydealz.de/deals/wester...externe-festplatte-fur-44599-amazones-1091236

 

[Benji18]

Ich denke mal, VW wird da in Zukunft etwas vorsichtiger sein. Vermutlich.
Die eine Milliarde an AMD?
Dass war doch Portokasse. Gegen die EU Strafe läuft die Berufung sogar immer noch.

Nein ich rede von der Strafe die durch den Vergleich mit der FTC (US Wettbewerbsbehörde) gemacht wurde, da geht es um den Compiler und die dadruch entstandene Marktmanipulation durch ausnutzen der Marktbeherrschenden Stellung.

 

[jemandanders]

Nein ich rede von der Strafe die durch den Vergleich mit der FTC (US Wettbewerbsbehörde) gemacht wurde, da geht es um den Compiler und die dadruch entstandene Marktmanipulation durch ausnutzen der Marktbeherrschenden Stellung.

Wie? Da ist Geld geflossen?
Ich dachte immer die hätten sich darauf geeinigt, die FTC zeigt öffentlich den erhobenen Finger und Intel macht kurz öffentlich den Bückling und dann Business as usual.
Ihren Compiler haben sie ja nicht so wirklich geändert oder?

 

[Benji18]

Wie? Da ist Geld geflossen?
Ich dachte immer die hätten sich darauf geeinigt, die FTC zeigt öffentlich den erhobenen Finger und Intel macht kurz öffentlich den Bückling und dann Business as usual.
Ihren Compiler haben sie ja nicht so wirklich geändert oder?

Ne aber aus der Strafe gab es auch ein paar auflagen also schon ein dududu ... weils nur reinschreiben mussten das der compiler nur bei intel cpus ordentlich funktioniert.

und sie mussten Grld an alle SW firmen zahlen due den compiler einsetzen damit diese eine Lib einbauen für none Intel cpus aja und Dell hat auch strafe zahlen müssen weil intel bitch 🤷🏻‍♂️

 

[jemandanders]

und Dell hat auch strafe zahlen müssen weil intel bitch

Jo. Michael Dell. The best Friend, Money can buy.
Dürfte sich dann über zukünftige Rabatte wieder geregelt haben.

 

[I'm unknown]

Nach der Logik darfst du auch mit keinem Kleinwagen auf die Autobahn, weil wenn du in einen Unfall mit 2 LKWs zerquetscht wirst

Bin gespannt ob das Ergebnis der Sammelklage teuer genug wird um solchen Unsinn weiter einzudämmen. Wenn SMR drinnen ist soll das auch abgegeben werden .

Unabhängig davon hinkt dein Vergleich jedoch: Ein SUV wird bei einem ungebremst auf fahrendem 40 Tonner deutlich unter die Größe eines Kleinwagen komprimiert wenn vor dem SUV ein weiterer Lkw steht. Man kann nur hoffen dass die Assistenzsysteme schnell erheblich zunehmen, die Fehlerquelle Mensch bleibt...

 

[Benji18]

Jo. Michael Dell. The best Friend, Money can buy.
Dürfte sich dann über zukünftige Rabatte wieder geregelt haben.

wie man aber an Mathlab sieht hats nix genutzt und es wird noch immer der Intel Compiler verwendet schade drum ^^ aber wenn Intel das nötig hat als durch wirklich gute Produkte zu punkten

@iamunknown

Ich gehe mal davon aus, dass hier WD einen ordentlichen Batzen Geld abdrücken darf, da man hier eine Serie für Raid bewirbt die das definitiv nicht sinnvoll nutzbar macht.

--> hätte man z.b. eine Red Serie für "Archiv mit SMR" gemacht für 1 od. 2 Bay NAS sehe ich das ja noch als durchaus sinnvoll ein aber so haben Sie sich den Quatsch selbst zuzuschreiben.

Aber wie man sieht war die "gier" größer und man hat halt gehoft nicht "erwischt" zu werden

 

[Luthredon]

Klar, daß das auf Dauer an die Substanz geht, oder?

Das weiß ich ehrlich gesagt nicht, hab mich da nie SO detailiert damit beschäftigt. Bei der Qualität von HDs war bislang allerdings eher der MTBF Wert interessant, der eigentlich keinen Unterschied zwischen den Betriebsarten macht (außer Stand-by natürlich). Ob jetzt also der Kopf über relevanten Daten fliegt und dabei schreibt und liest, oder ob die Platte nur rotiert, scheint nicht den großen Unterschied zu machen. Die Kopfbewegung an sich, also das 'Schrabbern', ist praktisch verschleißfrei. Wer schon mal eine 10-15 Jahre alte Platte zerlegt hat, kann sich von der Lagerung des Kopfträgers beeindrucken lassen - auch nach der langen Zeit. Und e-Magneten verschleißen nur auch nicht wirklich .

Der Stromverbrauch ist natürlich etwas anderes, hat aber nix mit der Ausfallrate zu tun (naja, nur sehr minimal).

Ergänzung (1. Juni 2020)

... aber bei HDDs gibt es schon seit so 10 Jahren ein Workload Rating, aber bei dem zählen die gelesenen Lesevolumen ebenso wie die geschriebenen Datenvolumen und bei HDDs von "totgeschrieben" ist reiner Schwachsinn.

Ah, interessant. Das wusste ich bislang nicht. Leicht zu finden ist die Angabe aber nicht, oder? Wie gesagt, die MTBF-Zeiten stehen halt immer 'vorndran' und können sich ja auch ordentlich unterscheiden, also zwischen 'Consumer-HDs' und RAID-, Server-, Profi-HDs. Muss ich mal auf die Suche gehen, guter Hinweis.

 

[mgutt]

und eben diese menge an überlappenden spuren bis zum nächsten unterbrechungspunkt nenne ich einen SMR-Abschnitt
Wenn |A| einen einzeln beschreibbaren Abschnitt bei CMR darstellt, sieht das bei SMR eben so aus |ABCDEFGHIJKLMNOPQRSTUVW|
will man nun den Inhalt von Sektor G löschen passiert erstmal garnix, außer dass das Dateisystem den Sektor als frei markiert. Einfach mal mit einem kleinen buchstaben marktiert
|ABCDEFgHIJKLMNOPQRSTUVW|
Wenn nun GXYZ geschrieben werden sollen schreibt die Platte
|ABCDEFGHIJKLMNOPQRSTUVW|XYZ....| <- eben zwei abschnitte, den ersten quasi 'unnötig' komplett neu

Dieses aufräumen ist soweit ich das sehe unnötig weil es nichts bringt. man kann in einem solchen abschnitt nicht einfach mitten drin losschreiben, sondern aufgrund des überschreibens lediglich früher aufhören.

Ja aber genau dieses "zwei Abschnitte" neu schreiben ist ja das, was so mega langsam ist. Du beschreibst es so als wäre das auf einer Spur, aber es läuft über mehrere Spuren. Stell dir vor, dass jeder Buchstabe eine Spur darstellt. Um dann an G zu kommen, musst der Kopf erstmal Spur Z anfahren, in den Cache lesen, dann Y, Dann X... Bis zur Spur H. Erst jetzt kann der Schreibkopf die Spur G beschreiben, dann H ... Bis zu Z. Genau dieser Spurwechsel macht SMR so langsam. Und damit das nicht dann passiert, wenn man schreiben möchte, macht das WD beim DMSMR im Hintergrund.

Edit: Es gibt einen interessanten Artikel von WD, der auch noch mal meine am Anfang gemachten Aussagen zu den dynamischen Sektoren bestätigt und dass DMSMR doch etwas anders funktioniert:
https://blog.westerndigital.com/dmsmr-device-managed-shingled-magnetic-recording/

Denn da steht, dass WD das SMR-Rad quasi neu erfunden hat. Denn im Gegensatz zu:

To accomplish the new write, the entire data segment (SMR Zone) needs to be re-written in order to preserve other data.

kopiert WD die Daten ganz woanders hin (ohne die Lücke):

This is where things get interesting. In order to re-write the data, all of the data within the same data segment (SMR zone) is relocated elsewhere. In doing so, the absolute address of the data is remapped.

Also das was ich bisher beschrieben habe, gilt nur für Seagates HMSMR. WDs DMSMR holt dagegen keine leeren Bereiche auf die obersten Spur, sondern kopiert sie einfach ganz woanders hin und ändert die Position des Sektors in einer Tabelle, die der Controller verwaltet. Also wie es auch bei SSDs gemacht wird.

Dadurch sind Schreibprozesse quasi immer schnell, aber wenn es nicht genug Leerlauf-Zeit gibt, kann DMSMR die Daten nicht ordentlich defragmentieren, was dann zu Lasten der Lesezugriffe geht:
"The property of SMR architecture also allows us to coalesce the data in cache more freely, mainly due to, again, LBA Indirection. Performance can be good when a burst of random writes is sequentialized into a local zone. Nevertheless, this burst of performance does come at a cost: data needs to be migrated to improve near-sequential read performance. However, with appropriate amount of idle time, such as in a typical NAS environment, this benefit can be easily harvested in the right workload."

Ich vermute, dass der Controller an Hand der sich wiederholenden Lesezugriffe lernt welche Blöcke besser zusammen liegen sollten. Jedenfalls ist mir sonst nicht klar was beim Leerlauf optimiert werden sollte um die Lesegeschwindigkeit zu steigern. Alles wird uns WD ja denke ich nicht verraten.

Jedenfalls wird das nichts an einer gewissen Inkompatibilität zu sektorbasierte Aktionen ändern wie es beim Rebuild von ZFS RAIDs Der Fall ist.

 

[antagonist99]

Es ist alles korrekt dokumentiert. Man muss nur lesen.
https://www.westerndigital.com/products/internal-drives/wd-red-hdd

Ach wirklich?

https://web.archive.org/web/2020041...gital.com/products/internal-drives/wd-red-hdd

Noch am 16. April war gar nichts dokumentiert. Aber schön, dass man ja 'nur lesen' müsse.

 

[alQamar]

Es mag richtig sein, das nicht auf allen Seiten die gleichen Infos stehen. Im Fall WD ist das auf den deutschen (Shop) Seiten immer noch so, Stand heute.
Das passiert bei docs.microsoft.com auch ständig und ist ggf. relevanter als die Wahl von Festplatten für das Zuhause übliche Backup / Datengrab.
Ich lese die Diskussion hier teils sehr emotionsgeladen. Als müsste man mit seinem NAS IOPS Rekorde in Microsoft diskspd oder Crystaldiskmark aufstellen.

@MichaG
https://www.guru3d.com/news-story/w...-nas-are-using-smran-issue-with-nas-raid.html

Dieser Artikel und die Stellungnahme von WD sind durchaus lesenswert und ich bin mit meinen EFAX HDDs bislang genau so zufrieden wie bisher mit der 2 TB EFRX, welche seit 2012 fehlerlos im Dauerbetrieb ist. Und das ist was das ich bei einer WD Blue, trotz PMR, nicht erwarten darf.

Fakt ist auch das die sequenziellen Schreib-und Leseraten bei dem 5400 RPM 6 TB Modell übertroffen wird, trotz SMR.
Mit Rapid Sector Mode hab ich heute "185 Gigabyte" mit Macrium in 1 Minute 10 restored.

Trotz SMR.

Ebenfalls kann ich in Storages Spaces RAID 1 locker 250 MB/ seq wegschreiben bei QD1.
Also über Performance kann ich nicht klagen.

Mein Standpunkt ist, das alle WD Platten neue Artikelbezeichnungen haben und bei anderen ggf. nicht. Insofern ist Informieren in jedem Fall möglich.

Gegenwärtig tauschen Händler auf Kulanz auch Platten aus.

 

[I'm unknown]

Mein Standpunkt ist das alle WD Platten neue Artikelbezeichnungen haben bei WD und bei anderen ggf nicht. Insofern ist Informieren in jedem Fall möglich.

Wenn nichts von SMR da steht kann man sich auch nicht "informieren". Da gibt es nichts daran zu rütteln.

Fakt ist auch das die sequenziellen Schreib und Leseraten bei dem 5400 RPM Modell übertroffen wird, trotz SMR.

Klar, bei sequentieller Last mag das gelten, wenn du aber viele kleine Dateien schreiben möchtest wird das bei allen Journaling-Dateisystemen problematisch. Vom Raid-Problem ganz zu schweigen. Und das konnte man eben vor dem Kauf nicht wissen.

 

[alQamar]

OK. Zäumen Wir das doch nochmal auf

Hat sich die Artikelbezeichnung schon vor dem "Skandal" geändert oder nicht?
Bitte um konkrete Antwort.


Wenn ich ein NAS betreibe, ob mit linuxoiden oder Windows dann weiß ich doch, daß ich bestenfalls immer die gleichen Platten für ein RAID nutzen muss.

Also hier Artikelbezeichnung und Firmware.
Im Business Umfeld ist das auch so.

Ein Motor mit 150 PS ist ja auch nicht immer gleich gut. Drehmomentverlauf, PS Leistung bei wie viel Umdrehungen, Verbrauch, Brennstoff, Zahnriemen oder Steuerkette, empfohlene Ölsorte etc

Entweder will oder muss man sich informieren, oder nicht.

Wenn jetzt Händler das nicht getan hätten, also EFRX und EFAX gleicher maßen verkaufen (wobei EFAX leider nicht bei allen WD Red = SMR ist)

Dann gibt es doch bei Erhalt der Ware die Prüfung und entweder Nutzung des Fernabsatzgesetzes oder sogar in diesem Fall Anfechtung des Kaufvertrages wegen Irrtum nach BGB (falsche Warenauszeichnung), da eben die Festplatten dann nicht baugleich sind.

Ansonsten gibt es Support und man fragt bestenfalls beim Hersteller wenn man unsicher ist. Presales etc.

Also wo siehst du das Problem?

Wenn ich etwas kaufen will, wo ich unsicher bin oder unerfahren, frage ich den Hersteller oder versuche meinem (Fach)Händler vertrauen zu schenken.

Ich kann natürlich auch viele Meinungen in Foren erhalten.

 

[I'm unknown]

Hat sich die Artikelbezeichnung schon vor dem "Skandal" geändert oder nicht?
Bitte um konkrete Antwort.


Wenn ich ein NAS betreibe, ob mit linuxoiden oder Windows dann weiß ich doch, daß ich bestenfalls immer die gleichen Platten für ein RAID nutzen muss.

Und wenn du nun lauter gleiche Platten mit SMR für ein RAID 5 kaufst und die Platten nicht mit SMR ausgezeichnet waren was hast du damit gewonnen?

 

[Bigeagle]

Du beschreibst es so als wäre das auf einer Spur, aber es läuft über mehrere Spuren. Stell dir vor, dass jeder Buchstabe eine Spur darstellt. Um dann an G zu kommen, musst der Kopf erstmal Spur Z anfahren, in den Cache lesen, dann Y, Dann X... Bis zur Spur H. Erst jetzt kann der Schreibkopf die Spur G beschreiben, dann H ... Bis zu Z. Genau dieser Spurwechsel macht SMR so langsam.

Für mein Beispiel ist es eigentlich egal wie groß die Abschnitte genau sind, dass die sich über mehrere Spuren erstrecken ist mit SMR ja schon vorrausgesetzt.

Aber was so nicht hinkommt ist der Glaube dass der Spurwechsel beim Beschreiben eines SMR-Abschnittes bremsen würde. Der dauert eher deutlich weniger als eine ms, dagegen ist die Zeit die für eine Umdrehung gewartet werden muss ein vielfaches höher.
Schließlich liegen die Spuren da direkt nebeneinander, also ist der Weg den der Arm schwenken muss minimal, das finden der Spur und nachjustieren geht bei gesunden Platten normalerweise auch schnell, besonders bei nahen Spuren. Afaik ist das schwerer je weiter sich der Arm bewegt hat weil dann vibrationen und ungenauigkeiten mehr reinspielen.
Die verlangsamung kommt fast ausschließlich durch die zusätzlich zu schreibende Datenmenge zustande.

Ansonsten bin ich mir nicht so sicher ob ich den WD Ansatz mag. Seagate scheint das zumindest anders gemacht zu haben. Aber wenn die Platte selbst noch mal garbage collection machen muss ... urks
ist vermutlich für desktopplatten ok, aber so vom grundgedanken her finde ich es irgendwie gruselig dass die platte ggf noch eine halbe ewigkeit nach der angeordneten aktivität aufräumt.
Zumindest habe ich nichts gesehen, oder gehört was darauf hinweist dass die archive hdds sowas tun und eben auch nichts dass das notwendig erscheinen lässt. aber ich denke ich probiere noch mal mein glück mit einem test der weniger einfach und sequentiell läuft.

 

[Holt]

Nur weil du es nicht besser weißt, ist nicht alles automatisch Fake.
https://blocksandfiles.com/2020/04/15/shingled-drives-have-non-shingled-zones-for-caching-writes/

Wo steht da was von:

Da bekannt ist, dass der Controller die Sektoren dynamisch verteilt

Außerdem ist der Alan Brown "a British university network manager" und kein WD Mitarbeiter. Bei der Aussage "When you write to a SMR disk it’s a bit like writing to SSD – no matter what sector you might THINK you’re writing to, the drive writes the data where it wants to, then makes an index pointing to it (indirect tables)." bezieht er sich klar auf den OnDisk Cache, was er CMR zone nennt. Dies wird auch klar, denn kurz darauf sagt er "In general, writes are to the CMR space and when the disk is idle the drive will rearrange itself in the background – tossing the CMR data onto shingled areas". Da es ein Cache ist, stehen die Daten dort unsortiert, wie bei jedem anderen Cache auch, das hatte ich ja auch schon geschrieben, aber danach werden sie dann auf ihre endgültige Position geschrieben und die ist für einen bestimmten LBA immer die gleiche Position, solange der Sektor nicht durch einen Reservesektor ersetzt wurde! Da ist nichts dynamisch das die Daten dann mal hier oder mal da landen und die HD Tune Benchmarks beweisen genau dies, denn sonst wären die Kurvenverläufe ganz anders.

Vielleicht weil dieses Modell einfach diese Charakteristik hat? Widerspricht allerdings auch den Tests mit HD Tune von Hardwareluxx:

HD Tune liest und schreibt in der Standardeinstellung nur 64k alle paar GB und bei weitem nicht durchgehend den ganzen Adressraum, die Daten bei den Schreibtests könnten also durchaus alle in den OnDisk Cache gepasst haben. Der Alan Brown sagt ja selbst:

WD40EFAX drive which I zero-filled averaged 40MB/sec end to end but started at 120MB/sec. (I didn’t watch the entire fill so I don’t know if it slowed down or paused).

Ja die Daten auf der Spur waren gemeint. Den Satz habe ich korrigiert.

Das ist das Problem: du schreibt das eine meinst aber hinterher dann was anderes. Wie soll man denn wissen das was andere gemeint ist? Der Computer weiß das auch nicht, der macht auch nicht was man will, sondern was man ihm sagt, wenn man format D: eingibt, dann hat man Pech gehabt wenn man eigentlich format E: gemeint hat.

Interessant auch seine Aussage zum IDNF Bug:

Alan Brown: Because I don’t have any Seagate SMR drives, I can’t test the hypothesis that the IDNF issue is a WD firmware bug rather than a generic SMR issue. But throwing an error like that isn’t the kind of thing I’d associate with SMR as such – I’d simply expect throughput to turn to shit.

Eben, man sollte erwarten das die Performance Grütze ist, aber keinen solche IDNF Fehler zu erhalten, daher sehe ich den Fehler klar als Zeichen für einen Bug.

Erst wenn Dateien gelöscht werden und der freie Platz beschrieben werden soll, dann kann dieser nicht beschrieben werden, solange dieser leere Bereich nicht auf die oberste Spur geholt wurde.

Ist weiterhin Quatsch, im SMR Bereich müssen alle Daten der Spuren gelesen werden, die beim Überschreiben mit überschrieben werden, dann werden die neuen Daten geschrieben und alle dadurch überschriebenen Daten ebenfalls erneut geschrieben. Es gibt keine Situation in der Daten nicht überschrieben werden können, dies geht immer, es dauert nur entsprechend lange. Er schreibt wie lange es dauern kann:

ZFS reports dozens of delays exceeding 60 seconds – the limit it measures for – and I measured one pause at 3 minutes

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.

Während auf einer CMR gelöschte Sektoren sofort wieder zur Verfügung stehen, folgen bei SMR ja aufwendige Aufräumarbeiten

Es gibt keine Aufräumarbeiten, nur das Schreiben der Daten von OnDisk Cache auf ihre finale Position, eben den immer gleichen Sektor dem der LBA zugeordnet ist unter dem sie geschrieben wurden und wo sie sofort gelandet wären, wenn der OnDisk Cache beim Schreiben schon voll war.

Einer dieser Nachteile war, dass in einem ZFS Raid der Controller mit einer Fehlermeldung (IDNF) antwortete, weil ZFS gezielt auf einen Sektor zugreifen wollte, der noch nicht "existiert".

Das ist Quatsch, jeder Sektor bis zum maximalen Sektor existiert immer und kann jederzeit gelesen oder beschrieben werden, die Red haben da klar einen Bug, wenn es bei ihnen anderes ist!

Eben weil der Controller noch nicht entschieden hat wo der liegen soll:
https://blocksandfiles.com/2020/04/15/shingled-drives-have-non-shingled-zones-for-caching-writes/

This seems to trigger a further problem on the WD40EFAXs where a query to check a sector that hasn’t been written to yet causes the drive to internally log a “Sector ID not found (IDNF)” error and throws a hard IO error from the interface to the host system.

Jede HDD muss jederzeit die Daten wiedergeben können, egal ob sie noch im DRAM Schreibcache, im OnDisk Cache oder schon auf ihrer finalen Position im SMR Bereich stehen! Wenn die Red dies nicht können, ist das klar ein Bug und wo der Controller die Daten ablegt, ist nur im Cache eine Frage die frei beantworten kann, am Ende liegen auf einer ganz bestimmten Position im SMR Bereich, da dort die LBAs immer einem ganz bestimmten und immer dem gleichen (außer eben wenn er defekt ist und dafür ein Reservesektor einspringt) physikalischen Sektor, was HDDs von SSDs unterscheidet, aber wenn es anders wäre, müsste sie eine genauso aufwendige Mappingtabelle verwalten wie SSD Controller es müssen und deren Größe beträgt normalerweise etwa so 1GB pro 1TB Kapazität, passt also nicht ansatzweise in den DRAM Puffer.

Hat man nun aber viele Daten auf der SMR und löscht etwas, dann kann dieser Bereich nicht neu beschrieben werden, weil der leere Block kleiner ist als der Schreibkopf:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-01-12_27_10-png.926843/[/IMG]

Dieser ist also so lange nicht nutzbar bis aufgeräumt wurde. Und aufräumen heißt in dem Fall, dass die darüberliegenden Blöcke nach unten verschoben werden:
[IMG]https://www.computerbase.de/forum/attachments/2020-06-01-12_29_41-png.926844/[/IMG]

So ist es aber nicht, wenn da der Sektor X überschrieben werden soll, dann landen die neuen Daten auch wieder genau auf dem Sektor, die in dem Sektor auf dem Bild rechts daneben werden dabei mit überschrieben und müssen daher vorher gelesen und nachher neu geschrieben werden. Dabei werden aber die Daten auf dem dritten Sektor von links überschrieben, also müssen diese auch vorher gelesen und danach wieder zurückgeschrieben werden, usw.

Dies wäre ja auch nötig wenn man es so machen wollte wie du glaubst, die Oberfläche ist ja fix und da verschiebt sich nichts, nur hätte man obendrein das Problem zu verwalten wo welche Daten nun tatsächlich stehen.

Und was das langfristig für die Fragmentierung der Daten bedeutet, muss ich denke ich nicht erklären.

Da es eben nicht so ist das die Daten auf eine andere Position verschoben werden, sondern gelesen und dann wieder auf ihre alte Position zurückgeschrieben werde, gibt es diese Fragmentierung auch nicht. Dein Verständnis von SMR ist schlicht falsch.

Also eigentlich sollte doch das Reduzieren der Platten immer Kostenvorteile bringen oder?

Nein, ganz offensichtlich kosten die Platte und ggf. die Köpfe mehr, der Controller dürfte auch aufwendiger sein, braucht zumindest ja DRAM Cache, also dürfte es schlicht teurer sein eine 14TB oder 16TB mit SMR zu bauen als ohne, auch wenn die mit SMR einen Platter weniger hat, warum sollte man es dann also machen, wenn es obendrein die Einsatzmöglichkeiten einschränkt.

Auf Geizhals steht SMR (kann falsch sein...) und die Cache Größe passte.

Technische Angaben sind bei Geizhals leider falsch und die WD Red 8TB, 10TB und 12TB haben auch 256MB Cache und die 14TB sogar 512MB und kein SMR, die Cachegröße ist also allenfalls ein Indiz, wenn auch nur ein schwaches.

Ich habe hier eine Samsung 950 Pro mit 512MB für 256GB

Da hat man wohl der Einfachheit halber die gleichen 512MB verlötet wie sie 950 Pro mit 512GB besitzt. Die Dinger waren ja damals teuer genug und Samsung baut die NANDs selbst, da konnte man es sich sicher leisten auch mal 256MB RAM zu viel draufzulöten. Das gab es auch bei anderen Modellen schon mal, dass da die kleinen Kapazitäten einfach die DRAMs der größerer Modelle bekommen haben, auch wenn gar nicht so viel benötigt wird.

Da ist die Frage womit man vergleicht. In der WD60EFAX sollen ja 2TB Platter stecken. Also die 6TB hat nur noch 3 statt 5 Platter.

Für 6TB sind schon lange keine 5 Platter mehr nötig, außer WD hat das Modell lange nicht aktualisiert und noch sehr alte Platter mit schon längst veralteter Datendichte verwendet. Die kommende 18TB (und 20TB SMR) sind die ersten WD mit 9 Platter, die 12TB Red und die 14TB sind also wohl 8 Platter und wenn 12TB mit 8 Platter gehen, sind also auch 6TB mit 4 Platter machbar. Ich sehe aber gerade, dass die News der 12TB Red vom Mai 2019 und die der 14TB vom Oktober ist, die neuen WD60EFAX vom Februar 2019, von daher macht es Sinn das man bei den Vorgängern noch 5 Platter genutzt hat, kommen doch die neuen Platter mit der jeweils höchsten Datendichte immer zuerst in den Modellen mit der höchsten Kapazität und erst verzögert in die kleineren Modelle. Trotzdem wäre es heute ja kein Problem eine 6TB Red mit CMR und 4 Platter zu bauen.

während vorher alle Modelle unterschiedlich große Platter hatten

Nein, 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:

Im Gespräch auf der IFA 2015 sagte der WD-Manager Jörg Andreas, dass er sich mit dem 3-TByte-Modell selbst auch nicht so ganz anfreunden könne. Die 3,5-Zoll-Platten dieser Serie enthalten jeweils eine Scheibe (Platter) pro TByte Speicherkapazität. Die 3-TByte-Platte sei eigentlich ein 4-TByte-Modell, bei dem man 4 Scheiben mit einer für die anderen Modelle nicht ausreichenden Kapazität einsetze. Schrott kann man diese Festplatten wohl dennoch nicht nennen, denn praktisch jede Festplatte wird mit defekten Sektoren ausgeliefert – es gibt ausreichend Reservesektoren, die in die Bresche springen.

Wenn nun GXYZ geschrieben werden sollen schreibt die Platte
|ABCDEFGHIJKLMNOPQRSTUVW|XYZ....| <- eben zwei abschnitte, den ersten quasi 'unnötig' komplett neu

Nein, macht sie nicht!

Wenn auf der einen Spur steht:
|ABCDEFGHIJKLMNOPQRSTUVW|
und auf der darunter die von ihr überlappend mit überschrieben wird steht:
|1234567890123456789012|
Und das große g soll durch ein kleines ersetzt werden, dann muss die Platte die Ziffern auf der unteren Spure einlesen, eine Umdrehung geht also dafür drauf. Dann überschreibt bei der nächsten Umdrehung die obere Spure und dabei automatisch auch die untere, so dass da steht:
|ABCDEFgHIJKLMNOPQRSTUVW|
|ABCDEFgHIJKLMNOPQRSTUVW|
Nun muss noch der alte Inhalt der unteren Spur wiederhergestellt werden, nach noch einer dritten Umdrehung steht da also:
|ABCDEFgHIJKLMNOPQRSTUVW|
|1234567890123456789012|
Obwohl sich im Beispiel nur 2 Spuren überlappen, braucht ich 3 statt bei CMR nur einen Zugriff und bei realen SMR Platten überlappen sich noch mehr als nur 2 spuren, da muss ggf. noch viele mehr erst eingelesen und wieder zurückgeschrieben werden. Da verrücken aber keine Daten ihre Position wie mgutt denkt.

Edit: Es gibt einen interessanten Artikel von WD, der auch noch mal meine am Anfang gemachten Aussagen zu den dynamischen Sektoren bestätigt und dass DMSMR doch etwas anders funktioniert:
https://blog.westerndigital.com/dmsmr-device-managed-shingled-magnetic-recording/

Das war mir neu, aber eine HDD weiß nichts von den Daten die auf sie geschrieben werden, also können sie damit nur ihre eigenen Metadaten meinen:

Our approach to DMSMR is dynamic. We designate various SMR zone sizes for different purposes and applications. Using machine learning and pattern recognition in our system, the drive detects types of data so that we can coalesce similar data types together to maximize performance. For example, logs and metadata for indexing or journaling of small block writes will be placed somewhere more advantageous for garbage collection, while large block transfers will be placed into large zones.

Wie die HD Tune Kurven zeigen, liegen bei ihr die niedrigen LBA auf den äußeren Spuren und dann fällt die Transferrate im typischen Verlauf zu den inneren Spuren hin ab, da liegen die LBA also auch genauso angeordnet wie bei allen anderen HDDs auch und nicht dynamisch mal hier und mal da auf andere SMR Zonen gemappt.

Ich vermute, dass der Controller an Hand der sich wiederholenden Lesezugriffe lernt welche Blöcke besser zusammen liegen sollten.

Und ich bezweifel das die Controller überhaupt genug Resourcen haben um so komplizierte Algorithmen umzusetzen und erst recht die ganzen dafür nötigen Daten zu verwalten. Die Hersteller schreiben immer von tollen und intelligenten Algorithmen, aber wenn man hinter die Kulissen schaut sind die in Wahrheit extrem simple, weil mehr einfach nicht machbar ist. So laden die Controller der SSHDs einfach die zuletzt mit kurzen Lesezugriffen gelesenen Daten in den NAND Cache und Marvell hat bei seinem Hyper Duo "A breakthrough embedded technology for 6Gb/s SATA controllers" z.B. im 9230 in Wahrheit die Umsetzung ganz simple gemacht: Die Cache SSD und die gecachte HDD laufen praktisch wie im RAID 1, geschrieben wird auf, gelesen aber eben von der SSD, nur dass eben der Adressraum der SSD kleiner als der der HDD ist und sobald von Adressen gelesen wird die oberhalb des Adressraums der SSD liegt, wird dann eben von der HDD gelesen und man hat keinen Cache mehr. Funktioniert in Benchmarks wo alle Daten auch auf der SSD liegen natürlich gut, aber von einer "breakthrough technology" zu reden ist total übertrieben, denn wenn die Daten jenseits des Adressraums der SSD stehen, können sie niemals gecacht werden. Aber kann man wirklich mehr von einem so kleinen Controller mit einer TDP von 1Watt wirklich mehr erwarten? Daher sollte man nicht alles glauben was an großartigen Beschreibungen von den Herstellern blumig formuliert wird, sondern sollte sich auch überlegen wie realistisch es ist das dies alles so ist wie man es aufgrund der Beschreibung glauben soll und die HDDs eben eben nichts von Partitionen, Filesystemen, Verzeichnissen oder Dateien. HDDs und SSDs stellen nur einen linearen Adressraum zur Verfügung und speichern überlicherweise pro LBA 512 Byte und sehen die ganze Zeit nur Befehle mit denen sie aufgefordert werden ab LBA x die folgendnen Y LBAs zu lesen oder zu beschreiben. Ob das Daten einer Datei, Metadaten des Filesystem oder auch die Partitiontabelle ist die da gelesen oder geschrieben werden weiß eine HDD oder auch SSD gar nicht. Wenn sie in einem RAID 0, 5 oder 6 arbeitet, dann steht die Partitiontabelle ggf. auch auf ihr, sondern auf einer anderen Platte des RAIDs und sie bekommt von allen Metadaten nur Fragmente ab, wie sollte ein Controller sowas überhaupt auswerten können, selbst wenn er dies versuchen würde?

Es mag richtig sein, das nicht auf allen Seiten die gleichen Infos stehen.

WD hat die Info über SMR erst kürzlich eingefügt, die HDDs wurden aber schon im Februar 2019 vorgestellt, ohne jeglichen Hinweis auf SMR zu geben.

 

[alQamar]

Und wenn du nun lauter gleiche Platten mit SMR für ein RAID 5 kaufst und die Platten nicht mit SMR ausgezeichnet waren was hast du damit gewonnen?

Beantwortet leider meine Frage nicht.

Im Moment (prozentual) jede Menge Geld 180 zu 210-240 Euro das Stück bei 6TB

höhere Speicherdichte, weniger Verbrauch
Hitze

Geräuschentwicklung ggf.

Garantiert aktuelle Platten / Herstellungsdatum

Ggf. weitere technische Verbesserungen wie Heliumfüllung oder nicht dokumentierte Weiterentwicklung.

Geringere Wahrscheinlichkeit von OEM Platten, siehe Warnhinweis Geizhals
(hier gilt was ich schon schrieb zur Abwicklung)

Siehe Specs der PMR 10 TB mit der 6TB bzw 8TB SMR/PMR.

Ergänzung (2. Juni 2020)

WD hat die Info über SMR erst kürzlich eingefügt, die HDDs wurden aber schon im Februar 2019 vorgestellt, ohne jeglichen Hinweis auf SMR zu geben.

Siehe oben. Hinweis auf Änderungen gleich Artikelbezeichnung?

 

[DarkSoul]

Stand denn bei den Festplatten früher (tm) immer drauf, was für eine Technik sie intern nutzen? 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.

OT: VW ist ja anscheinend auch wieder "Opfer" der Ami-Methoden. Was ich sehr schade finde: Die Fahrzeuge sind wirklich gut, in manchen, mittlerweile aussterbenden Nischen (MVP), sogar quasi konkurrenzlos (z. B. Touran oder Sharan (inkl. Tocherfabrikat Seat Alhambra). Statt die Verantwortlichen zu bestrafen, werden alle bestarft, auch die Mitarbeiter, die dafür gar nichts können und deren Existenz davon abhängt. Und das auch noch zu Corona-Zeiten, man merkt: Die Amis verfolgen ein anderes Ziel: Sie wollen Konkurrenz vom US-Markt drängen, mit allen Mitteln.