WD20SPZX (2TB 2,5" SMR) bei Updates extrem langsam

[albert66]

Ich habe auf meinem T400 mit Win7->Win10 upgrade vor 2 Jahren auch die HD gewechselt auf 2TB Western DigitalWD20SPZX. Im Prinzip tut die bei "normalem" Gebrauch. Bei Win10 Monats-Updates säuft die regelrecht ab, gegenüber dem Desktop um ein vielfaches an Laufzeit. Keine Fehler, aber teilweise Zugriffszeiten im 3stelligen msec (bis 700) Bereich. Ich bin leider erst sehr spät über die SMR-Technik gestolpert, die das auch erklären würde. Da etliche Partitions wegen drei Systeme drauf sind, war das dann vermutlich kein idealer Kauf. Stört allerdings in erster Linie mit 3-4 Std update-Zeit, je nach MS patch-Massaker. Ansonsten .... eigentlich ok.

Gibt es spezielle Treiber für diese SMR-Dinger oder Win-Parameter oder irgendwelche Tricks, da etwas schneller zu machen. Im Taskmanager ist die bei den Monats-Patches 1-2 Std auf 100% mit transferraten z.T. im zweistelligem kB/sec Bereich. Dann wieder MB/sec. Das geht oft schon beim Download los und dann weiter beim Install. Die kleiner Security updates laufen normal durch, zwar länger als bei, Desktop, aber nicht extrem.

Irgendwelche Tips, Einstellungen, Checks ?? Hat sich bei den Updates irgendetwas geändert (wird da evtl. der Write-Cache abgeschaltet o.ä.)?? Mir fällt es eigentlich erst seit 21H2 so richtig auf.

 

[pumpkin0]

Davon habe ich noch nie gehört... Hast du dafür eine Quelle? Solche Abschnitte kenne ich wiederum nur von SSDs, bei denen TLC/QLC-Speicher die Zellen zunächst im SLC-Modus beschreiben, aber bei SMR-HDDs ist mir das neu.

https://de.wikipedia.org/wiki/Shingled_Magnetic_Recording deutet es unter "Geschwindigkeit und Verwaltung" an. Die englische Version drösselt es nach consumer und Server Platten auf.

Im Endeffekt verhalten sich die Consumer SMR Festplatten wie mäßig gute QLC SSDs mit kleinem SLC Cache: die ersten x Gigabyte gehen richtig gut, danach braucht das System einige Zeit um die Daten in den SMR-Bereich zu verschieben. Video Fans laufen in die Wand wenn sie gleich alles auf einmal drauf kopieren wollen. RAID syncs haben das gleiche Problem. Aus Erfahrung: 16TB sync kann eine Woche dauern... Windows User mit wenigen GB pro Stunde Änderungen merken nicht dass es eine SMR ist.

Dummerweise publizieren die Hersteller die Größe vom Cache nicht. Und die Platten können intern fragmentieren wenn man sie als Windows Platte nutzt. Da hilft dann nur noch ein secure erase laufen zu lassen.

 

[albert66]

SSDs kann man auch mit MBR verwenden. Wenn du per dd klonst, läuft die Kiste wie vorher (nur viel schneller).

Danke an beide (mit @moronoxyd). Da habe ich dann irgendwo eine Fehlinfo erwischt oder etwas mit Win11 durcheinander geworfen. Dann ist das Thema erledigt und es kommt eine SSD mit MBR rein. Weiß der Henker wo bzw. wie ich die Fehlinfo erwischt habe. Danke an das Forum auch zu dieser Diskussion. Also .... die Würfel sind gefallen, muß nur noch ein paar andere Baustellen bedienen, Garten, Hund, Familie, etc. Gibt noch ein Leben ohne IT .

Headcrashes sind mir zur Genüge ex-beruflich und auch zu Hause geläufig. Beruflich waren einige bei meinen Kunden (Mainframe) ausschließlich Klimaanlagen-Probleme oder Umzüge in neue RZ, da passierte immer an irgend einem Teil etwas. Die Fehlermeldungen kamen immer früh genug um die Einheit zu isolieren und auf Reserve zu restoren. Allerdings ging es oft sehr schnell und ein kompletter Backup war selten noch möglich. Privat habe ich bisher nur höher drehende second hand HDs gecrashed, darunter ein komplettes Packerl IBM-SCSI mit 9000 ?? (weiß ich nicht mehr genaue Drehzahl, von einem Bekannten wegen SCSI-Ende auf seinen Servern geschenkt bekommen). SCSI läuft in zwei PCs bei mir noch unter OS/2 mit HD, Scanner und CD-Brenner (HP, wollen nicht kaputt gehen, SCSI HD IBM ebenfalls). Ich habe wie @Mornsgrans nur noch 5400 am laufen, den schnelleren Rest fasse ich nicht mehr an, und von denen laufen alle noch.

@cuco: Naja, PC schnell genug ist relativ. Wenn ich vergessen hatte MS updates während Urlaub oder 2.Wohnung auf suspend zu setzen, MS mir einen Brummer schickt, ging manchmal 3-4 Stunden so gut wie nichts mehr. Wenn ich dann schnell mal eine Route zum Ausflugsziel nachschauen möchte oder Öffnungszeiten irgendwo, Telefon-Nr., .... war der Tag zum Teufel. IPhone is' nich', nur altes Telefonier-Handy von Motorola, was verblüffenderweise sich Win10 sich sogar noch gekrallt hat, um via dessen Modem fall-back zu machen. Nur zum Browsen taugt es Null, dafür nehme ich dann den Thinkpad überall mit. Ist OT, habe ich nur wegen dem Win10 Fall-back erwähnt. Das Minihandy hing zum Aufladen am USB und Win10 war bei einem Update. Beim restart anschließend wollte Win10 das alte Handy, habe Win10 gewähren lassen und später getestet - funktionierte tatsächlich mit moderaten Antwortzeiten.

Zur Kontrol-Bereich-Diskussion: die wd20spzx hat 128MB Cache, und der dürfte bei größeren Updates schnell weg sein, wenn auch noch lange tracks geschrieben werden müssen (wie es für SMR beschrieben wird - egal welche Block-Methode).

Ansonsten .... die Infos reichen mir jetzt super, um es mit SSD anstelle der wd20spzx zu versuchen.

 

[hikaru]

RAID mit mdadm oder aber auch mit ZFS und btrfs.

Die Details müsste ich auffrischen, aber bei mir ist hängegeblieben, dass RAID (wozu auch zfs und btrfs gehören) ebenfalls eher schlecht im Zusammenspiel mit SMR-HDDs ist.
Der Kernel läuft dabei wohl in Timeouts, die im schlimmsten Fall zu Lesefehlern führen. Es soll wohl mittlerweise Patches dafür geben, aber auch das ist nur dunkle Erinnerung.
Meine SMR-HDDs laufen alle ohne RAID mit je einer einzelnen Partition und ext4-Dateisystem.

Zum Thema SSDs:
Meine Älteste ist über 10 Jahre alt (mSATA, 80GB) und läuft derzeit als Bootmedium in einem sporadisch genutzten T430. Mittlerweile hat sie eher wenig zu tun, aber sie war jahrelang Bootmedium zweier Hauptsysteme.

 

[albert66]

Ich habe bei Western Digital etwas recherchiert. Die wd20spzx ist per specs "Implementation of SMR for the following products using SMR recording technology is device-managed SMR". Dazu hat WD eine Seite https://blog.westerndigital.com/dmsmr-device-managed-shingled-magnetic-recording/ zur Erklärung.

Unabhängig vom SSD-Austausch schreibe ich evtl. WD-Service mal an. Ich muß nur vorher deren zwei Programme installieren und mir die HD damit ansehen. Möglicherweise gibt es Firmware-Updates oder ähnliches. Wenn die Diagnose bei mir nichts ergibt, ....... die schreiben in dem Artikel, daß sie mit speziellen Workloads entwickelt haben. Etwas vornehm zurückhaltend in dem Artikel:

Specified workloads — Our drives are built to work in specific environments. The firmware is tailored for a specific application use case and as such is designed with extremely varying zone sizes, buffering and flush policies of how data is committed.

We collect a lot of field data to deeply understand workloads, data usage, idle time, read/write ratio and other characterization so we can design firmware that is highly-optimized for specific segments (e.g. personal computing, NAS, etc.). As our drives are optimized for specific purposes, performance may be impacted if used for a purpose for which it was not designed.

MS updates gehören anscheinend nicht dazu .

Ich muß allerdings eine Besonderheit erwähnen, bisher vergessen, war aber bereits bei der vorherige 1TB CMR HD identisch: Da ECOMStation/2 wie OS/2 max. 500GB mit Standard CHR-Geometrie zum Booten unterstützt, habe ich die HD mit anderer Geometrie formatiert (255 Sector per track bei 2TB). Windows kümmert sich allerdings nicht darum, sondern hat seine eigene (Standard-)Geometrie. Allerdings laufen bei mir auch der Desktop mit gleicher Formatierung. Kann natürlich noch ontop bei updates verlangsamen, wenn als Workbereich freier Space genutzt wird. (Ich weiß auf Anhieb jetzt nicht, ob alle Win10 Partitions gleich formatiert sind).

 

[hikaru]

ECOMStation/2 [..] OS/2

Vorweg: Ich habe keine Ahnung von diesen Systemen.

In Anbetracht dessen, dass die jeweils letzten Versionen laut Wikipedia inzwischen fast ein, bzw. über zwei Jahrzehnte alt sind, vermute ich, dass deren Partitionsschemata nicht an 4kB-Blöcken moderner HDDs ausgerichtet sind, sondern nach wie vor an 512Byte-Blöcken. Stimmt die Vermutung?
Falls ja, dann würde das bedeuten, dass 7 von 8 I/O-Operationen "suboptimal" ablaufen. Bei sequenziellen Zugriffen sollte auch hier NCQ Einiges retten können, aber zaubern kann es auch nicht. Kombiniert man das mit der Schreibcharakteristik von SMR, dann landet man direkt in der I/O-Hölle.

 

[Schwartz]

OP, du sprichst von Disketten und alten HDDs die robust sind. Ja, das waren sie mal. Die neueren sind alles andere als langlebig. Ist wirklich zur Verschleißware geworden, zumindest so mein Eindruck. Mir sind genug Platten nach 1-2 Jahren abgeraucht.

Ich bin auch Späteinsteiger bei SSDs, und das war denke ich auch genau richtig so. Mitterweile sind die Dinger wirklich langlebig, gute Controller vorausgesetzt, und an die Schreiblimits kommst du bei hartem Gebrauch vielleicht wenn das Baby volljährig geworden ist. Hol dir ne 870 Evo und werde glücklich. Mit einer SMR als Systemplatte ist das doch reiner Masochismus.

 

[albert66]

.... Partitionsschemata nicht an 4kB-Blöcken moderner HDDs ausgerichtet sind, sondern nach wie vor an 512Byte-Blöcken. Stimmt die Vermutung? ...

Im Prinzip ja, aber ....... ich habe bei IBM im Übergang von der 1401 auf die /360 er Systeme angefangen und die Historie mit erlebt. Ich will nicht zu weit ausholen. Bis zur /360 waren Speicher-Bereiche variabel möglich, Rechner und ext.Speicher. Mit der /360 fing im Rechner die Blockstruktur an, bei den Platten erst viel später. Ein Steuereinheit pufferte und per Zugriffsmethode (heute Treiber) ging es zur "Application". Die /360-CPU hatte bereits µCode und taktete in den 60ern im nsec-Bereich. Großer Sprung...... es hat sich nach und nach fast alles fürs I/O-Geschäft hierarchisch verlagert. Teile der "Treiber" in den µCode der Steuereinheit (Controller), der Puffer wurde zum Cache und inzwischen sitzt der Controller mit µCode (Firmware) und Cache auf dem Gerät (Device). Aus variablen Datensätzen (records) wurden feste Sectoren und letztlich wurden nur noch per cache komplette Tracks verarbeitet. Die CHR bzw. CHS direkt Zugriffe verschwanden eigentlich recht schnell, Wiki ist mit https://en.wikipedia.org/wiki/Cylinder-head-sector da etwas verschwurbelt. Die ersten Platten ab ~120GB nutzten praktisch nur noch LBA-Addressing, bereits in den 80ern. Die Sektorgröße war eigentlich nur noch bei FAT interessant, HPFS/NTFS waren da außen vor. Die Sektoren mußten bei FAT größer werden, um mit der 16/32bit-Adressarchitektur die HD überhaupt noch nutzen zu können. Für Direkt-Zugriffe wurde auf dem Mainframe CKD - Logic verwendet, https://en.wikipedia.org/wiki/Count_key_data, FORTRAN unterstützte das direkt. Es wurde über ("hash-")Algorithmen auf den Track positioniert und nach dem gewünschten Key gesucht. Dieses ganze Zeugs ist heute auf dem Device mit angebautem Controller in der Firmware verbaut. Soweit im Galopp durch IBM-Nomenklatur "der CMR" seit den 60ern. Einen Teil alter Handücher habe ich noch aufgehoben, aber ........ (irgendwann Altpapier).

Unterm Strich sind wir heute grob betrachtet soweit, daß m.W. komplette Tracks eingelesen werden (CMR), bzw. alles was mit einer Umdrehung am R/W-Kopf vorbei kommt. Die ganze CHS/LBA Rechnerei wird von der Firmware inkl. Cache gemacht, in (meistens ) Zusammenarbeit mit dem Driver. Auf den Firmware-Algorithmen sitzen die Firmen drauf (Asset). Beim CMR spielt daher die Sektorgröße kaum noch ein Rolle. Bei den alten Systemen OS/2 und ECOMStation wird per MBR noch mit 512bytes gerechnet und bei >512GB platzt der Cylinder-Count, deshalb wird da in der Geometrie SPT auf 127 für 1TB und 255 für 2TB gesetzt. Soweit ich gesehen habe, schert sich Win10 nicht darum und setzt seine (klassischen NTFS) Partitions auf SPT 63 zurück.

Da vermute ich jetzt sehr stark, daß WD mit seiner Device-Managed-SMR mir per Firmware bereits einen gehörigen Strich durch die Rechnung macht, weil die alte Head-Track -Sector Organisation außer der (Mehrfach-)Schmalspurschreiberei in völlig neuer Blockstruktur arbeitet. Mit physischen I/O anhand der Sektorengröße hat daß nichts mehr zu tun, bereits bei CMR (wo immer der komplette Track im Cache ist). Leider, ..... alles Firmen Internals (auch bei IBM). Man kann es etwas knacken, wenn man Tabellen schreibt und die Adressprünge variiert. Da kriegt man bei der CPU und HD recht schnell heraus, wie weit der Cache genutzt wird. Bei SMR werde ich mal etwas aus der Gruft holen und und die HD triezen........ (solange sie noch im T400 ist).

Danke für die Diskussionen und sorry für den alten "stuff". Zur Modernität: die ersten /360er takteten bereits in nsec-Bereich und für H/W-Fehlersuche hatten wir schweineteuere Tektronix-Oszillokope, die bis aus 2 oder 5 nsec auflösen mußten. Diagnose-Programme waren rudimentär im µCode, ansonsten schrieb man selber nach und nach welche, bzw. bekam die vom Labor. Es war noch Händeschütteln mit den Bits .

Trotz allem: ja, ja, ja, ....... SSD kommt auch bei mir, zumindest anstatt SMR.

 

[cuco]

https://de.wikipedia.org/wiki/Shingled_Magnetic_Recording deutet es unter "Geschwindigkeit und Verwaltung" an. Die englische Version drösselt es nach consumer und Server Platten auf.

Danke für die Info bzw. den Link! Das ist wirklich völlig an mir vorbeigegangen!

 

[albert66]

Ich habe WesternDigital kontaktiert (0080027549338 für DE) ...und der erste Anruf ein klassischer Helpdesk: nach Abfrage von Kragenweite, Schuhgröße, ..... der Fachmann. "Performace ??" -> "Da müssen Sie die Platte neu formatieren. Dann sind dort schöne große Blöcke drauf und alles gut". Gebetsmühle für alle Einwände. Zuletzt - "da brauchen wir dann ganz viele Logs, Windows usw.". Zwischenstop eingelegt und auf deren Dashboard 3.7.2.5 zur Analyse verwiesen, das bei mir auf zwei Rechnern bei jeweis einer der WD-HD abstürzt, Desktop eine WD rot 1TB Work-HD und auf dem Thinkpad die 2,5" WD Blue SMR mit 2TB. Vorschlag von mir: Hilfe zu dem Absturz und dann erst nächster Schritt. "Jaaaa, es gibt aber auch noch andere Tools und wir brauchen viele Unterlagen .....". Da habe ich abgebrochen und mir nur noch die EMailAdresse geben lassen, an die ich die vorhandenen Umterlagen und den Request schicken kann (bevor ich mir die in 2 Semester clicken durch die Pages selber hole). Das Dashbord funktioniert bei mir bei allen Platten auf Desktop und T400, außer den zwei Ausnahmen, d.h. auch Hitachi 4x 1TB USB und die WD 2TB red wird erkannt. I.d.R. bieten die Hersteller bei eigenen Produkte etwas mehr an als oft die allgemeinen Tools. War früher bei Seagate jedenfalls so. Ich war selber im Service (Mainframe, RZ), habe Service ausgebildet (bei Kunden). Er hatte zwar meine Schmerzgrenze noch nicht erreicht, aber es reichte trotzdem. Ich melde mich wieder, wenn bzw. falls ich zu der SMR Geschichte etwas handfestes von WD habe.

Frage an die HD-Spezies:
Ich habe Speccy, HWInfo, Crystalinfo und disksmartview (Nirsoft) - jeweils aktuelle Downloads getestet. Funktionieren , aber ..... außer fehlerfreien HDs (0 r/w-errors) habe ich nichts feststellen können. Gibt es noch andere Tools free- oder billig-tools, die empfehlenswert sind ??

Nur als Info (vermutlich Eulen nach Athen):
Für die Performance reicht eigentlich bereits der Taskmanager, der die Transferraten aktuell wiedergibt. Für die SMART-Werte habe ich einen Tip von
https://stackoverflow.com/questions/22758629/how-to-read-hdd-s-m-a-r-t-attributes genutzt,
Get-Disk | Get-StorageReliabilityCounter | Select-Object -Property "*" im Admin-Mode per Powershell gibt gleich die wichtigsten Felder für alle installierten HD lesbar aus.

Grüße Albert66 (Peter)

 

[cuco]

Was erwartest du denn von WD? Dass sie dir sagen: "Ja, SMR-Festplatten sind wirklich so ein Mist, wie Sie selbst feststellen..."? Schließlich arbeitet sie doch so, wie sie kann.

Ebenso zu den Tools: Es gibt viele Tools - die Frage ist, was du damit erreichen möchtest?

 

[albert66]

(1) Was erwartest du denn von WD? .....
(2) Ebenso zu den Tools: Es gibt viele Tools - die Frage ist, was du damit erreichen möchtest?

(1) Fix für deren Tool "Dashboard" und evtl. haben die Firmware-Updates oder -Unterschiede bei gleicher SMR-HD. Da hat der Help-Desk nicht einmal die Frage richtig verstanden, nur "neu formatieren und alles wird gut....". Der glaubt vermutlich immer noch, daß 512 bytes sectors auch bei der SMR-HD physisch geschrieben werden.

(2) Es gibt noch einen Sack voll weiterer Parameter als nur SMART-Daten. Auf etlichen wird WD die Hand drauf halten, aber vielleicht bringen andere Tools etwas mehr als die von mir getesteten und/oder erlauben evtl. Modifikationen.

Die Problematik ist die logische Organisation bzw. Konzept zwischen Cache, der physischen Struktur und der Adressierung und das ist reine Firmware-Sache. Daß Nachbarthreads geschrieben werden müssen ist eine Sache, wenn dabei aber Caching nicht mehr funktioniert, ist es irgendwo faul. Ein physischer Track wird praktisch pro Kopf in ~0,2 msec geschrieben (zumindest kann man das). Wenn da (mehrfach gesehen) längere Strecken mit 700msec je Zugriff gearbeitet wird, paßt einfach einiges nicht mehr zusammen (freundlich ausgedrückt). Die HD an sich ist ja fehlerfrei und prinzipiell ok.

Ich kenne ähnliche Verhältnisse aus der (Anfangs-)Zeit der "partitionierten Mainframes" (IBM LPAR), wo ein großer Hersteller (nicht IBM) per Microcode mit starren Zeitscheiben scheduling machte und Anwender des Kunden Minuten Lieferzeiten am Bildschirm hatten. Das Konzept wurde geändert. (ich war kurz weg, Ergänzung). Microsoft machte den gleichen Fehler bei den ersten Windowsversionen mit Multitasking vs. OS/2, was damals beide gemeinsam im Kernel entwickelt hatten. Wenn I/O-interrupts zu lange zurück gehalten werden ("auflaufen"), kippt das Gesamt-Systemverhalten und schafft es einige Zeit nicht, die Warteschlangen ab zu arbeiten. Da kommen dann solche Zeiten, wie auch andere berichtet haben, schnell zusammen. Manchmal helfen simple Eingriffe, das Problem zumindest zu entschärfen. Hier wird offensichtlich der (komplette ?) Cache zu lange blockiert und bei Write-Caching geht dann die komplette Anwendung und evtl. weitere (bei kompletter Sperre) zum Teufel.

Das Konzept ............. ich bin einfach (ex-beruflich) neugierig geblieben.
Trotzdem Frage: weitere interessante Tools in der Richtung bekannt ??

 

[cuco]

(1) Fix für deren Tool "Dashboard"

Ok, das wäre eine Sache, aber wenn ich deinen Beitrag oben richtig verstehe, hast du bei den Nachfragen dazu abgebrochen.

und evtl. haben die Firmware-Updates

Die würdest du auf der Homepage direkt zum Download bekommen. Da brauchst du nicht den Support.

oder -Unterschiede bei gleicher SMR-HD.

? Warum sollte es? Auf magische Art und Weise soll die eine SMR-HDD aus der gleichen Serie besser funktionieren als die andere? Das Problem ist ja nicht mal, dass es an der Serie der HDDs liegt, sondern an der Technik an sich.

Da hat der Help-Desk nicht einmal die Frage richtig verstanden, nur "neu formatieren und alles wird gut....". Der glaubt vermutlich immer noch, daß 512 bytes sectors auch bei der SMR-HD physisch geschrieben werden.

Ich glaube, der Support wusste genau so wenig, was du jetzt eigentlich möchtest - außer dich darüber beschweren, dass deine HDD zu langsam ist. Man kann halt nichts daran ändern, dass SMR diese Effekte aufweist.

(2) Es gibt noch einen Sack voll weiterer Parameter als nur SMART-Daten. Auf etlichen wird WD die Hand drauf halten

Sicher?

aber vielleicht bringen andere Tools etwas mehr als die von mir getesteten und/oder erlauben evtl. Modifikationen.

Was willst du den modifzieren? Es gibt da praktisch nichts einzustellen bei HDDs und daher auch nichts zu modifizieren.

Die Problematik ist die logische Organisation bzw. Konzept zwischen Cache, der physischen Struktur und der Adressierung und das ist reine Firmware-Sache. Daß Nachbarthreads geschrieben werden müssen ist eine Sache, wenn dabei aber Caching nicht mehr funktioniert, ist es irgendwo faul. Ein physischer Track wird praktisch pro Kopf in ~0,2 msec geschrieben (zumindest kann man das). Wenn da (mehrfach gesehen) längere Strecken mit 700msec je Zugriff gearbeitet wird, paßt einfach einiges nicht mehr zusammen (freundlich ausgedrückt). Die HD an sich ist ja fehlerfrei und prinzipiell ok.

200 Millisekunden für das Schreiben eines Tracks? Das wären aber monströs schnelle HDDs. Hier werden nicht 512 Bytes gecacht und dann weggeschrieben, hier geht es um weit größere Mengen. Wir reden hier von Größenordnungen von einigen Hundert Megabytes pro Zone. Oft ist wohl 256 MB. Das heißt, dass zum Schreiben eines Sektors in so einer Zone 256 MB gelesen werden müssen, dann wird der eine Sektor im RAM der HDD verändert und dann werden 256 MB wieder weggeschrieben. Wenn da nicht intelligent vorverarbeitet werden würde, dann würden wir hier eher von 3-6 Sekunden Wartezeiten bei solchen Zugriffen reden. Du kannst froh sein, dass es schon "nur" 700ms sind. Wenn die Caches, die offenbar genutzt werden, noch weit größer sind als diese 256MB pro SMR-Zone, dann reden wir - nach Füllung des Caches - ggf. sogar über noch weitaus größere Wartezeiten, bis der Cache weggeschrieben ist.
Aber ja, die HDD ist an sich fehlerfrei und OK und arbeitet im Rahmen ihrer Möglichkeiten. Dass da irgendwas nicht zusammenpasst sehe ich nicht so.

Ich kenne ähnliche Verhältnisse aus der (Anfangs-)Zeit der "partitionierten Mainframes" (IBM LPAR), wo ein großer Hersteller (nicht IBM) per Microcode mit starren Zeitscheiben scheduling machte und Anwender des Kunden Minuten Lieferzeiten am Bildschirm hatten. Das Konzept wurde geändert. (ich war kurz weg, Ergänzung). Microsoft machte den gleichen Fehler bei den ersten Windowsversionen mit Multitasking vs. OS/2, was damals beide gemeinsam im Kernel entwickelt hatten. Wenn I/O-interrupts zu lange zurück gehalten werden ("auflaufen"), kippt das Gesamt-Systemverhalten und schafft es einige Zeit nicht, die Warteschlangen ab zu arbeiten. Da kommen dann solche Zeiten, wie auch andere berichtet haben, schnell zusammen. Manchmal helfen simple Eingriffe, das Problem zumindest zu entschärfen. Hier wird offensichtlich der (komplette ?) Cache zu lange blockiert und bei Write-Caching geht dann die komplette Anwendung und evtl. weitere (bei kompletter Sperre) zum Teufel.

Du kannst da gerne Anekdoten auspacken, wo schon mal ähnliche Wartezeiten auftraten. Das ändert nichts daran, dass SMR-HDDs einfach Mist sind und du diese Grenze gerade kennen gelernt hast. Daran ändert aber auch kein anderer Scheduler oder sonst was dran. Da ändert nur eine HDD mit konventioneller Auzeichnungstechnik was dran. Oder eben eine SSD.

 

[IBM_Fan001]

wenn das noch eine echte Festplagte wie früher ist und keine SSD dann ist das immer alles sehr langsam und normal das es sehr langsam ist.

 

[albert66]

Ich habe ja kapiert, das SMR vom Prinzip her bereits Nachteile hat. Unterschiede könnte es durchaus bei Firmware zum gleichem Typ geben. Ich werde mich eh' noch weiter einlesen, weil die SMR-Cache Konzepte vermutlich unterschiedlich sind. Daß der Cache komplett weggeschrieben muß/wird .......... wieso ?? (Cache ist nicht gleich Buffer, und falls doch, ist das kein Cache mehr.) Da wird es sicher Unterteilungen geben wie auch die Zonen auf der Platte. Caching ist ja längst keine Erfindung nur für SMR, das Konzept gibt es lange genug. An Caching-Details haben sich schon genügend Labors die Zähne ausgebissen.

Ich habe jetzt erst einmal Platten-Bestandsaufnahme gemacht, weil ich noch 2 PCs zusammenbauen will und etwas WD 2TB Lagerbestand habe. Nachdem feststeht, das u.U. einzelne aus dem Zeitraum 2019/20 SMR sein könnten (ohne Kennzeichnung), werde ich SMR-Typen sicher nicht einbauen und allenfalls als Backup nutzen.

Für die WD-Anfrage muß ich noch Daten sammeln. Da läuft mir nichts weg ...............

wenn das noch eine echte Festplagte wie früher ist und keine SSD dann ist das immer alles sehr langsam und normal das es sehr langsam ist.

Das Problem ist, das speziell bei großen (identischen) Win-updates der Unterschied T400 mit SMR und Desktop mit klassischem CMR 4-6 Std zu 1/2 Std ist, grob über den Daumen so passiert. Deshalb bin ich ja erst "aufgerüttelt" worden - als SMR Dummy (nicht darauf geachtet). SSD ist ausreichend bekannt, nur wegen Anfangsfehlern bisher gemieden worden. Das SSD-Thema haben wir durch (inzwischen akzeptabel fehlerfrei, habe ich dazu gelernt).

 

[albert66]

Nochmal einen Nachtrag (für SSD-Muffel und noch-HDD-Liebhaber ): nach Bestandsaufname sind meine nachgekauften 3.5" WD20[10]EFRX NAS typen (red) nach aktuellen WD-Infos CMR Platten. (product-brief-western-digital-wd-red-plus-hdd.pdf von Nov. 2022)

Als Ersatz für 2x 2,5" WD20SPZX (SMR) hatte ich mir 2x Seagate ST2000LM015 zugelegt und prompt daneben gegriffen. In den älteren Verkaufsprospekten wurden die mit "perpendicular" bezeichnet (ab 11/2016 updated dann SMR). Das hatte ich ohne weitere Zusatzbemerkungen und älteren Prospekt als "CMR" aufgefaßt. Inzwischen hat Seagate für alle Barracuda eine Übersicht. Per barracuda-2-5-DS1907-3-2005US-en_US.pdf (Stand Mai 2020) alles SMR.

Jetzt werde ich Umtausch der noch verpackten 2,5" versuchen und mir WD10JFCX zulegen. 1TB muß dann wie bei Win7 vorher auch reichen, mal sehen, wie das abmagern klappt (3 Betriebssysteme). Die WD10JFCX wird als 2,5" NAS HD (red) angeboten und bei https://nascompares.com/answer/list-of-wd-cmr-and-smr-hard-drives-hdd/ als CMR HDD gelistet.

Ich habe auf dem T400 eComStation/2 installiert, wozu ich wegen >512GB HD eine andere Geometrie formatieren muß. Zusätzlich plus XP und Win10 (als Win7 upgrade) gibt das in der Summe relativ viele MBR-Partitions. Das kollidiert vermutlich sehr kräftig mit dem SMR Konzept und bei größeren Datenbewegungen säuft die SMR-HD mit Minuten response-Zeiten ab.

 

[bodu]

Eine 174g externe Festplatte meldet sich als (auf dem Gehäuseaufkleber steht PN: 1D6APB-500 2TB):

smartctl --all /dev/sdc
smartctl pre-7.5 2024-10-26 r5632 [x86_64-w64-mingw32-w11-24H2] (CircleCI)
Copyright (C) 2002-24, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Seagate Samsung SpinPoint M9T
Device Model: ST2000LM003 HN-M201RAD
Firmware Version: 2BC10007
User Capacity: 2.000.398.934.016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Rotation Rate: 5400 rpm
Form Factor: 2.5 inches

eBay-Artikelnr.:267012899913 nennt S.M.A.R.T Werte zu einer ST2000LM003.
Nein, das Angebot stammt nicht von mir.


Hier eine 130 g externe Festplatte
Model Family: Seagate Mobile HDD
Device Model: ST2000LM007-1R8174
User Capacity: 2.000.398.934.016 bytes [2,00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical


Eine XP Partiton fing bei 63 Sektoren an.
Verwendet das T400 noch 240 Heads im BIOS?
Versuche die Partitionen im 4096 Bytes Unterteilung anzulegen.
Zu eComStation/2 passe ich. Eine OS/2 Warp Version 3 CD liegt hier im Regal.

BTW: SSD beißen nicht den Benutzer

 

[albert66]

Versuche die Partitionen im 4096 Bytes Unterteilung anzulegen.

Ich habe ja seit Jahren den T400 am Laufen. Zuerst Win7 pro 64kB, dazu mit XP und eCS/2. Ich habe später, nachdem eCS/2 in SATA AHCI lief, XP praktisch aufgegeben (XP kann AHCI nicht). Nutze nur noch die XP-Bibliotheken via Win10 (Office 2003, altes Help, u.a.). Ich fummele an den MBR-Partitions nicht mehr herum, weil alles läuft.

Die Reihenfolge zur Installation war tückisch genug, vorformatiert alles mit DFSEE, vom Stick gebootet. WIN7 hat bei Install C-H-S sowieso wieder geändert, aber nur seine Partitions. Damit war eCS/2 außen vor und blieb ok. Diese ersten Partitionierungen habe ich mir dokumentiert, weil ich die mehrfach geübt habe(n mußte) . Nochmal - freiwillig no ...
Gruß Peter

Nachgesehen: die Install-"Doktorarbeit" der drei Systeme lief im Sommer 2013, etlice Seiten Doc fabriziert, da steige ich nicht mehr ein
Für die OS/2 Desktops habe ich Warp 4 (noch Original verpackt) und ECWS CP2, einmal client einmal Server. eCS/2 nur wegen SATA.