News Ohne Ausnahme: Mit Toshiba verschweigen alle HDD-Hersteller SMR-Technik

[AlphaKaninchen]

...mich wundert das Verhalten meines RAID10 auf einer Synology 918+:

Dort sind

• 2x WD RED 6TB WD60EFRX-68L0BN1
• 2x WD RED 6TB WD60EFAX-68SHWN0

installiert, und zwar ganz bewusst so, daß in jeder RAID1-Gruppe eine (alte) ERFX und eine (neue) EFAX gemischt sind: Ich wollte das Risiko vermindern, daß mir eine komplette RAID1-Gruppe stirbt, wenn darin nur alte ERFX sind - das aber nur am Rande.

Ich habe gerade eine 67 GB grosse Zip-Datei vom Mac auf das NAS geschrieben - ohne einen Einbruch der Schreibrate zu beobachten, der ja mit SMR nach dem Vollaufen des Plattenchache zu beobachten sein müsste. Ist aber nicht - siehe Screenshot. Wieso?

Mir fallen nur zwei Erklärungen ein:

a) die alte EFRX übernimmt die Daten gewohnt schnell und fungiert quasi als 'Cache' wenn sich die lahme SMR -EFAX beim Spiegeln der Datein in der RAID1-Gruppe Zeit lassen sollte (bitte beachten: Ich habe ein RAID10, bestehend aus zwei RAID1 im RAID0-Verbund). Dann müsste nach dem Schreiben aber noch anhaltende HD-Aktivität beobachtbar sein - ist sie aber nicht...

b) meine im August 2019 gekauften WD RED 6TB WD60EFAX haben noch kein SMR. Kann es sein, daß das erst danach eingeführt wurde?

Zumindest aufgrund der Performance sehe ich momentan keine Notwendigkeit, die EFAX auszutauschen - obwohl mir dabei gar nicht wohl ist und der Finger schon auf dem Bestellknopf für zwei Enterprise-Class-Platten kreiste...

Was ist da los? Warum sehe ich keinen Einbruch der Transferrate? Ich habe zwar einen SSD-Cache, aber das ist nur ein Lese-Cache...

Anhang anzeigen 904191

simpel, kein Workload der eine SMR Platte in Probleme bringt, du kommst schlicht nicht aus der CMR Schreiben raus. Du müsstest entwieder Dateien überschreiben oder deutlich Größer Dateigrößen nehmen. Außerdem hat auch dein NAS wahrscheinlich einen Cache in form von RAM.

 

[Holt]

wird versucht die Datei zu reparieren (zB. mit den Parity Daten bei RAID-5/6 bzw. der Kopie der Datei bei RAID-1).

Das macht jede ordentliche Hardware- und Software RAID auch, wenn die Platte einen Lesefehler statt der Daten zurückgibt und dies macht jede HDD, wenn die Daten nicht zur ECC hinter dem Sektor passen und auch nicht anhand der ECC korrigiert werden können.

Man kann dem NAS sogar gelegentlich den Befehl geben, die Datenintegrität des kompletten Datensatzes zu verifizieren. (Data Scrub)

Auch diese Funktion hat jedes ordentliche HW- und SW RAID.

Man kann es wirklich nur an der Track density erkennen. Man könnte es noch am TRIM Support in Wort 69 oder 169 im Kapitel "4.3.1 Identify Device command" erkennen, aber dort geben sie scheinbar nicht den korrekten Wert an, sondern 0000h.

Die Seagate HDDs mit SMR haben keine TRIM Unterstützung (dies haben meines Wissens nur die neue von WD) und damit sind die Device Ident Daten korrekt.

 

[Nolag]

Die Seagate HDDs mit SMR haben keine TRIM Unterstützung (dies haben meines Wissens nur die neue von WD) und damit sind die Device Ident Daten korrekt.

Hier sind zwei CrystalDiskInfo Screenshots einer ST2000DM008 und einer ST1000LM049, die TRIM Support zeigen. Das Product Manual der ST2000DM008 enthält also in Kapitel 4.3.1 falsche Angaben.

 

[Naturtrüb]

Genau beantworten kann ich es nicht, aber die SMR Platten haben wohl Support für Trim. Schau mal im NAS ob da irgendwo die SMART-Werte aufgelistet sind, da müssten auch die unterstützten Features aufgelistet sein. Wenn da TRIM steht, ist es SMR.
Zur besseren Orientierung: Da dürfte zusätzlich noch S.M.A.R.T, APM, NCQ als Features stehen.

...bei den S.M.A.R.T-Werten steht nichts von Trim und - das ist das tolle - im Speicher-Manager lässt sich dort, wo sich bei SSDs normalerweise TRIM einschalten lässt, nicht aktivieren - weil dort kein TRIM angeboten wird:

https://www.synology.com/de-de/knowledgebase/DSMUC/help/DSMUC/StorageManager/volume_ssd_trim

Ein smartctl im Terminal liefert:

=== START OF INFORMATION SECTION ===
Vendor: WDC
Product: WD60EFAX-68SHWN0
Revision: 0A82
User Capacity: 6,001,175,126,016 bytes [6.00 TB]
Logical block size: 512 bytes
Physical block size: 4096 bytes
LB provisioning type: not reported [LBPME=1, LBPRZ=0]
Rotation Rate: 5400 rpm
Form Factor: 3.5 inches
Logical Unit id: 0x50014ee2bbdce661
Serial number: WD-W(...)
Device type: disk
Local Time is: Sun Apr 19 23:13:56 2020 CEST
SMART support is: Unavailable - device lacks SMART capability.

Sollte die EFAX tatsächlich erst ohne SMR gebaut worden sein? Das wäre ja der Hammer, wenn SMR nicht nur nicht dokumentiert, sondern bei unveränderter Modellbezeichnung einfach eingeführt worden wäre...

Ergänzung (19. April 2020)

simpel, kein Workload der eine SMR Platte in Probleme bringt, du kommst schlicht nicht aus der CMR Schreiben raus. Du müsstest entwieder Dateien überschreiben oder deutlich Größer Dateigrößen nehmen. Außerdem hat auch dein NAS wahrscheinlich einen Cache in form von RAM.

...zum einen läuft auf dem NAS als Dateisystem BTRFS, das ist copy-on-write. Da wird nichts überschrieben, zumindest nichts, was das Dateisystem nicht als löschbar markiert hat. Zum anderen war das im Test eine 67 GB grosse Zip-Datei deren Trasfer etwa 6 Minuten gedauert hat (geschätzt) und das NAS hat 8 GB RAM, in welchen Cache soll sowas passen?
Der Transfer hat die ganze Zeit über etwa 114 MB/s gehalten, das ist das Limit von GBit-Ethernet. Von den SMR-Festplatten werden dagegen Schreibraten-Einbrüche von unter 30 MB/s berichtet...

 

[AlphaKaninchen]

BTRFS also überschreibt die Platte nie Daten oder anderst gesagt keine Probleme mit SMR. (Außer bei ehr großen Datenmengen)
Wohersoll ich wissen das ihr NAS nur 8GB RAM hat?

PS: ich nutze selbst BTRFS, kenne Funkionen (und Probleme)

 

[Naturtrüb]

BTRFS also überschreibt die Platte nie Daten oder anderst gesagt keine Probleme mit SMR. (Außer bei ehr großen Datenmengen)

...67 GB am Stück würde ich doch für "groß genug" halten...

Wohersoll ich wissen das ihr NAS nur 8GB RAM hat?

...für eini NAS von der Stange ist das schon ziemlich viel. Kisten, bei denen 67 GB im RAM-Cache landen, laufen wohl kaum noch unter "NAS"... ;-)

 

[Holt]

Sollte die EFAX tatsächlich erst ohne SMR gebaut worden sein?

Kann sein, es ist aber eher unwahrscheinlich dies mit dieser Ausgabe zu belegen, da hier beim Auslesen offenbar etwas schief gelaufen ist:

SMART support is: Unavailable - device lacks SMART capability.

Denn die Platten unterstützen natürlich S.M.A.R.T., aber hier konnte es nicht ausgelesen werden, was verschiedene Gründe haben kann, aber eben dafür sorgt, dass es nicht als Beweis für oder gegen irgendwas taugt.

 

[AlphaKaninchen]

...67 GB würde ich doch für "groß genug" halten...

Sie müssen aus dem CMR schreiben raus, das macht die Platte solange sie ohne SMR genug Platz hat, so 60% des freien platzes sollte der Kopiervorgang schon haben...

 

[Naturtrüb]

Denn die Platten unterstützen natürlich S.M.A.R.T., aber hier konnte es nicht ausgelesen werden, was verschiedene Gründe haben kann, aber eben dafür sorgt, dass es nicht als Beweis für oder gegen irgendwas taugt.

...stimmt natürlich, ich müsste die Platte ausbauen und direkt in per SATA an eine Linux-Kiste anschliessen, die ich gerade nicht greifbar habe - da wäre die Sache eindeutig. Andererseits bietet mir die Synology kein TRIM zum aktivieren an - was sie ja eigentlich müsste, wenn es verfügbar wäre. Bei SSDs ist dessen Aktivierung in der GUI der Synology ja auch vorgesehen. Kann natürlich sein, daß sie erkennt daß es eine HDD ist und daher die Option streicht...

Ergänzung (19. April 2020)

Sie müssen aus dem CMR schreiben raus, das macht die Platte solange sie ohne SMR genug Platz hat, so 60% des freien platzes sollte der Kopiervorgang schon haben...

...na, dann kann ich ja noch eine Weile damit leben... ;-)

 

[fuyuhasugu]

Die Platte fängt also an zu stottern.

Du nennst es stottern, ich nenne es halt langsam. Wir meinen das Gleiche.

Ist nun der Cache randvoll, so werden keine neuen Schreibbefehle mehr entgegen genommen, bis z.B. 10% des Caches wieder frei sind. Hier wurde einfach die Cachinglösung nicht sauber implementiert.

Nach dieser Definition wäre eine saubere Implementation eine SMR-Platte mit >>95% CMR/PMR-Cache.

 

[Hayda Ministral]

... oder eine SMR-Platte deren Cache nur soweit genutzt wird dass sie ihn innerhalb der üblichen Zeit, also ohne dass es seitens Host als Timeout interpretiert wird, geleert bekommt.

Im Artikel zu WD wird kurz erwähnt dass es Device Managed SMR und Host Managed SMR gibt. Instinktiv würde ich vermuten, dass das beschriebene Verhalten des Cachemanagement bei HMSMR ok wäre, hier aber bei DMSMR fehl am Platz ist.

 

[fuyuhasugu]

... oder eine SMR-Platte deren Cache nur soweit genutzt wird dass sie ihn innerhalb der üblichen Zeit, also ohne dass es seitens Host als Timeout interpretiert wird, geleert bekommt.

Um das zu garantieren, müsste man die maximale Übertragensrate bzw. die innerhalb einer gewissen Zeitraums maximal übertragbare Datenmenge begrenzen. Aber wer außer Datenbank-Admins kennt schon solche Kenngrößen für eine voraussehbare Zukunft? Es wird wie immer auf nichtssagende "bis zu"-Angaben hinauslaufen.

 

[AlphaKaninchen]

@fuyuhasugu Bei denn Exos Festplatten gibt Seagate mindestschreibraten an

 

[Holt]

oder eine SMR-Platte deren Cache nur soweit genutzt wird dass sie ihn innerhalb der üblichen Zeit, also ohne dass es seitens Host als Timeout interpretiert wird, geleert bekommt.

Meines Wissens nach leeren die Platten ihren OnDisk Cache (also die CMR Bereiche) nur im Idle und daher entstehen Wartezeiten die länger als der Timeout des Hosts sein können nur durch Schreibzugriffe, aber eben nicht nur das Leeren des OnDisk Caches. Die Probleme mit ZFS bei den WD SMR HDDs dürfte aber nicht daran liegen, denn ZFS wartet meines Wissens nach sehr lange auf eine Antwort, nur Hardware RAID Controller sind da streng und warten meistens nur 8s auf eine Antwort, bevor sie eine HDD als Defekt einstufen.

 

[xexex]

Hardware RAID Controller sind da streng und warten meistens nur 8s auf eine Antwort, bevor sie eine HDD als Defekt einstufen.

Es gibt nicht mal eine Handvoll Hersteller von Hardware Raid Controllern und zumindest bei LSI ist dieser Wert konfigurierbar.

Eigentlich wäre es sogar unlogisch, wenn ein Controller nur 8s wartet, denn meines Wissens sind 7s nur für SAS definiert und bei SATA waren es schon immer 30s.

Es ist ja nicht so als wüsste so ein Controller nicht, ob er eine SAS oder SATA Festplatte anspricht. Die Probleme wirst du eher bei Software haben, wo die Leute dann einfach irgendwelche Standardwerte übernehmen.

 

[fuyuhasugu]

@fuyuhasugu Bei denn Exos Festplatten gibt Seagate mindestschreibraten an

Bist du dir sicher, dass du nicht die "max. kontinuierliche Datenübertragungsrate OD (MB/s) " meinst?
https://www.seagate.com/files/www-c...s/exos-x-14-channel-DS1974-5-1912DE-de_DE.pdf

Übrigens verweist Seagate bei den Exos mit SMR explizit auf "Archivierung von Daten im Cloud-Speicher, selten benötigterDaten (Cold Storage) und Online-Archivierung"
https://www.seagate.com/files/www-content/datasheets/pdfs/exos-5e8DS1954-2-1712DE-de_DE.pdf

 

[tom9865]

Nein, denn auch die Seagate IronWolf ST6000VN001 NAS Platte und sogar diese SkyHawk 2TB bis 8TB haben SMR. Aber trotzdem würde ich nur Seagate kaufen, wenn ich Wert darauf lege zu wissen ob die Platte SMR hat oder nicht, einfach weil man dies bei den Seagate Platten anhand der Angabe der Track density im Product Manual sehen kann. Leider machen weder WD noch Toshiba so umfassende technische Angaben und hoffentlich folgt Seagate diesem schlechten Beispiel nicht, aber solange sie noch so umfassende Angaben veröffentlichen, kann man bei ihnen sehr genau erkennen welche Modelle SMR haben und welche nicht.

Hi, danke für den Hinweis. Ich warte dazu gerade noch auf Antwort vom Seagate Support - seit gestern .
Also das heißt es ist sehr wahrscheinlich / sicher, dass die Seagate IronWolf ST6000VN001 SMR Techologie nutzt habe ich verstanden aufgrund der Track Density Angabe. Das heißt dann im Umkehrschluss, dass man (aktuell) bei der Pro Version - Seagate Ironwolf Pro - ST6000NE000 - dann mit Track density 371 sehr sicher eine CMR HDD hat?! Habe ich doch so korrekt verstanden, oder?

Siehe Manual: https://www.seagate.com/files/www-content/product-content/ironwolf/en-us/docs/100844774g.pdf

Offiziell hat Seagate SMR für die ST6000VN001 noch nicht eingeräumt... und leider finde ich nirgends belastbare Aussagen. TRIM wird bei dem modell nicht als unterstützt angezeigt.

Echt verwirrend. und anscheinend muss man wohl bei Use Case nicht (nur) Datengrab besser etwas mehr Geld ausgeben und auf die Pro Versionen setzen?!

-------------------
Update 20.04. 17:39:
Der Seagate Support hat mir jetzt gerade folgendes zurück gemeldet:
"Thank you for contacting Seagate Support.
I was able to confirm that the Ironwolf and Ironwolf Pro drives do have CMR technology.
Your case number is..."

 

[Nolag]

Offiziell hat Seagate SMR für die ST6000VN001 noch nicht eingeräumt... und leider finde ich nirgends belastbare Aussagen. TRIM wird bei dem modell nicht als unterstützt angezeigt.

Die ST6000VN001 hat die gleiche Bauform wie die Barracuda Compute ST6000DM003 mit SMR. Da das Chassis bereits über 2 Jahre alt ist, ist es vermutlich zu alt um TRIM Unterstützung zu besitzen. Seagate hat hier also vermutlich das gleiche getan wie WD und eine günstige Desktopplatte mit SMR zu einer NAS Platte deklariert.

 

[xexex]

Also das heißt es ist sehr wahrscheinlich / sicher, dass die Seagate IronWolf ST6000VN001 SMR Techologie nutzt habe ich verstanden aufgrund der Track Density Angabe.

Ich habe doch bereits eine Datenbank aller möglichen Platten verlinkt.
https://rml527.blogspot.com/2010/10/hdd-platter-database-seagate-35.html

Deine Antwort hättest du so möglicherweise auch schneller haben können.

 

[tom9865]

Sieht mir auch so aus. Ich habe bei Seagate jetzt noch einmal konkret mit den drei Artikelnummern angefragt:

• Ironwolf ST6000VN001 - sieht wohl nach SMR aus
• Ironwolf ST6000VN0033 - sieht nach CMR aus
• Ironwolf pro ST6000NE000 - sieht nach CMR aus

Mal schauen was als Antwort kommt.

Grüße,
Tom

Ergänzung (20. April 2020)

Ich habe doch bereits eine Datenbank aller möglichen Platten verlinkt.
https://rml527.blogspot.com/2010/10/hdd-platter-database-seagate-35.html

Deine Antwort hättest du auch schneller haben können.

Danke für den Hinweis. Mir erschließt es sich leider daraus nicht direkt. Werde ich mir nochmal anschauen.