Extreme Einbußen bei der Festplattenleistung

Extreme Einbußen bei der Festplattenleistung

Grundlegende Hardwareinformationen:
Bei der betreffenden Festplatte handelt es sich um eine Seagate BarraCuda 4 TB (Modellnummer: ST4000DM004). Weitere Einzelheiten finden Sie in der Ausgabe im hdparm -IAnhang am Ende.

Beschreibung des Problems und Tests:
Das Problem scheint auf den ersten Blick das Zwischenspeichern der auf die Festplatte zu schreibenden Daten zu sein, obwohl die Schreibgeschwindigkeit langsamer ist. In diesem Fall scheinen die Dinge jedoch nicht so einfach zu sein.

Kopieren von Dateien (auf einem NTFS-Dateisystem):
Beim Schreiben einer relativ großen Datenmenge sinkt die Leistung des Laufwerks plötzlich und stark. Normalerweise wäre dies so einfach wie das Zwischenspeichern von Dateien im RAM, wonach die Festplatte danach eine Weile funktioniert. Hier jedoch /proc/meminfoscheint das beobachtete Verhalten beim Überwachen der Datei (unter Ubuntu) dies nicht zu unterstützen. SogarnachWenn Sie die Daten schreiben (entweder große Dateien oder mehrere kleinere) und aufrufen sync, wird die Menge des „schmutzigen“ Speichers eine Zeit lang weiter abnehmen und dann fast vollständig zum Stillstand kommen. Er wird weiter abnehmensehrlangsam, bis es manchmal schließlich schneller wird. Dies kann sich wiederholen, je nach der verbleibenden Datenmenge. Das Lesen des Geräts ist auch extrem langsam, wenn die Schreibgeschwindigkeit abnimmt, und bleibt es auch nach syncAbschluss noch eine Weile, wenn dies im „langsamen Modus“ geschieht.

Diese ersten Tests wurden sowohl unter Ubuntu 21.10 als auch unter Windows 10 durchgeführt und zeigten ein ähnliches Verhalten.

Zusätzlicher Hinweis für Windows:
Als die Festplatte nach Abschluss des Kopiervorgangs weiterhin langsam war und ich versuchte, Dateien von der Festplatte zu lesen (z. B. beim Abspielen eines Videos, das immer wieder verzögerte), zeigten sowohl der Ressourcenmonitor als auch der Task-Manager einen hohen Prozentsatz der Festplattennutzung auf dem Gerät an (100 % oder nahe daran), während die tatsächlich angezeigte Geschwindigkeit <1 MB/s betrug. (Das Betriebssystem konnte an einem Punkt auch vollständig einfrieren, aber das kann damit direkt zusammenhängen oder auch nicht.)

Festplatten-Benchmarks:
Um herauszufinden, ob dies am Dateisystem oder an der Hardware selbst liegt, habe ich mit dem gnome-disksDienstprogramm Benchmarks auf dem Gerät durchgeführt. Das Ergebnis eines solchen Benchmarks, das ich hier zeigen werde, veranschaulicht, was ich oben beschrieben habe: Die Lese- und Schreibgeschwindigkeiten fielen ab einem gewissen Punkt stark auf fast Null ab und erholten sich dann später (blau und rot sind jeweils die Lese- und Schreibgeschwindigkeiten bei jeder einzelnen Probe, die an Stellen von außen nach innen auf der Festplatte genommen wurde, insgesamt 1000; die grünen Punkte und Linien entsprechen dem Zugriffszeit-Benchmark, der von den anderen getrennt ist):

Lese-/Schreibbenchmark

Beachten Sie, dass das Benchmarking-Tool meines Wissens nach Faktoren wie den Schreibcache eliminiert. Darüber hinaus /proc/meminfowurden während der langsamen Zeiträume ohnehin nur wenige bis gar keine Daten angezeigt, die darauf warten, geschrieben zu werden; der vollständige Inhalt ist in den Anhängen zu sehen.

Wenn die Schreibvorgänge im Benchmark deaktiviert sind, tritt dieses Phänomen nicht auf. Allerdings scheint es in den inneren Bereichen der Festplatte zu einem anomalen, plötzlichen Geschwindigkeitsabfall zu kommen:

Nur-Lese-Benchmark

(Der Ort der Abnahme istnichtvon der aufgewendeten Zeit, sondern tatsächlich von der physischen Position auf der Festplatte, wie andere Benchmarks mit einer anderen Sample-Nummer zeigen, bei denen der Cut-off an der gleichen Stelle erfolgt.)

Äquivalente Benchmarks auf anderen, vermutlich intakten Festplatten im System liefern die erwarteten, regulären Ergebnisse wie diese:

Lese-/Schreib-Benchmark auf intakter Festplatte

Fazit / Frage:
Daraus schließe ich, dass das Problem wahrscheinlich durch einen Hardware- oder Firmware-Fehler verursacht wird, es kann aber sein, dass ich eine Reihe von Dingen übersehen habe.

Was könnten die wahrscheinlichen Ursachen für das dargestellte Phänomen sein? Welche nächsten Schritte sollte ich unternehmen, um das Problem weiter zu diagnostizieren? Für jede Hilfe bin ich sehr dankbar.

Anhänge:
Detaillierte Hardwareinformationen (wie von ausgegeben hdparm -I):

/dev/sdb:

ATA device, with non-removable media
        Model Number:       ST4000DM004-2CV104
        Serial Number:      ZFN3J8RH
        Firmware Revision:  0001
        Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0
Standards:
        Used: unknown (minor revision code 0x006d)
        Supported: 10 9 8 7 6 5
        Likely used: 10
Configuration:
        Logical         max     current
        cylinders       16383   16383
        heads           16      16
        sectors/track   63      63
        --
        CHS current addressable sectors:    16514064
        LBA    user addressable sectors:   268435455
        LBA48  user addressable sectors:  7814037168
        Logical  Sector size:                   512 bytes
        Physical Sector size:                  4096 bytes
        Logical Sector-0 offset:                  0 bytes
        device size with M = 1024*1024:     3815447 MBytes
        device size with M = 1000*1000:     4000787 MBytes (4000 GB)
        cache/buffer size  = unknown
        Form Factor: 3.5 inch
        Nominal Media Rotation Rate: 5425
Capabilities:
        LBA, IORDY(can be disabled)
        Queue depth: 32
        Standby timer values: spec'd by Standard, no device specific minimum
        R/W multiple sector transfer: Max = 16  Current = 16
        Recommended acoustic management value: 208, current value: 208
        DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
             Cycle time: min=120ns recommended=120ns
        PIO: pio0 pio1 pio2 pio3 pio4
             Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
        Enabled Supported:
           *    SMART feature set
                Security Mode feature set
           *    Power Management feature set
           *    Write cache
           *    Look-ahead
           *    Host Protected Area feature set
           *    WRITE_BUFFER command
           *    READ_BUFFER command
           *    DOWNLOAD_MICROCODE
                Power-Up In Standby feature set
           *    SET_FEATURES required to spinup after power up
                SET_MAX security extension
           *    48-bit Address feature set
           *    Mandatory FLUSH_CACHE
           *    FLUSH_CACHE_EXT
           *    SMART error logging
           *    SMART self-test
           *    General Purpose Logging feature set
           *    WRITE_{DMA|MULTIPLE}_FUA_EXT
           *    64-bit World wide name
                Write-Read-Verify feature set
           *    WRITE_UNCORRECTABLE_EXT command
           *    {READ,WRITE}_DMA_EXT_GPL commands
           *    Segmented DOWNLOAD_MICROCODE
           *    unknown 119[6]
           *    unknown 119[7]
           *    Gen1 signaling speed (1.5Gb/s)
           *    Gen2 signaling speed (3.0Gb/s)
           *    Gen3 signaling speed (6.0Gb/s)
           *    Native Command Queueing (NCQ)
           *    Host-initiated interface power management
           *    Phy event counters
           *    READ_LOG_DMA_EXT equivalent to READ_LOG_EXT
           *    DMA Setup Auto-Activate optimization
                Device-initiated interface power management
           *    Software settings preservation
                unknown 78[7]
           *    SMART Command Transport (SCT) feature set
           *    SCT Write Same (AC2)
           *    SCT Data Tables (AC5)
                unknown 206[7]
                unknown 206[12] (vendor specific)
                unknown 206[13] (vendor specific)
           *    DOWNLOAD MICROCODE DMA command
Security:
        Master password revision code = 65534
                supported
        not     enabled
        not     locked
                frozen
        not     expired: security count
                supported: enhanced erase
        490min for SECURITY ERASE UNIT. 490min for ENHANCED SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000c500c6a79fae
        NAA             : 5
        IEEE OUI        : 000c50
        Unique ID       : 0c6a79fae
Checksum: correct

/proc/meminfowährend des ersten Benchmarks, als die Lese-/Schreibgeschwindigkeit langsam war:

MemTotal:       16323712 kB
MemFree:         9894056 kB
MemAvailable:   12815716 kB
Buffers:          138380 kB
Cached:          3038420 kB
SwapCached:            0 kB
Active:          1533040 kB
Inactive:        4396560 kB
Active(anon):       2960 kB
Inactive(anon):  2817480 kB
Active(file):    1530080 kB
Inactive(file):  1579080 kB
Unevictable:          32 kB
Mlocked:              32 kB
SwapTotal:      17577980 kB
SwapFree:       17577980 kB
Dirty:               176 kB
Writeback:             0 kB
AnonPages:       2752844 kB
Mapped:           694816 kB
Shmem:             73200 kB
KReclaimable:     137092 kB
Slab:             260112 kB
SReclaimable:     137092 kB
SUnreclaim:       123020 kB
KernelStack:       13872 kB
PageTables:        33292 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    25739836 kB
Committed_AS:    9749696 kB
VmallocTotal:   34359738367 kB
VmallocUsed:       76616 kB
VmallocChunk:          0 kB
Percpu:             8128 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
ShmemPmdMapped:        0 kB
FileHugePages:         0 kB
FilePmdMapped:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
Hugetlb:               0 kB
DirectMap4k:      512904 kB
DirectMap2M:     7813120 kB
DirectMap1G:     8388608 kB

Antwort1

Die Seagate ST4000DM004 verwendetSMRum Daten auf die Plattenoberfläche zu schreiben. Das bedeutet, dass zum Schreiben eines einzelnen Bytes möglicherweise mehrereGigabyte.

Bei "normalen Nutzungsmustern" (wie sie von Festplattenherstellern und nicht von Benutzern definiert werden!) stellt dies kein großes Problem dar - die Daten werden auf eineCMRCache am äußeren Rand der Festplatte. Später, wenn die Festplattennutzung abnimmt, verschiebt die Firmware das Datum an seinen endgültigen Platz in einem SMR-Band.

Beim gleichzeitigen Schreiben größerer Datenmengen ist dieser CMR-Cache erschöpft und der E/A-Prozess in SMR-Bändern muss übernehmen – dies ist um Größenordnungen langsamer.

Nota bene: Dies ist kein RAM-Cache, sondern ein kleiner Teil der Festplattenoberfläche, der in CMR geschrieben ist (d. h. ohne überlappende Spuren), um den SMR-Horror für Benutzer weniger sichtbar zu machen.

Antwort2

Festplatten schreiben Daten in Sektoren auf Spuren. Allerdings gibt es eine Grenze, wie nahe Spuren beieinander platziert werden können, ohne sich gegenseitig zu stören.

Festplattenhersteller erkannten, dass das Problem der gegenseitigen Interferenz benachbarter Spuren gemildert werden konnte, wenn sie das traditionelle Modell des wahlfreien Schreibzugriffs aufgaben und große Datenbereiche sequenziell schrieben. Jede geschriebene Spur überlappte sich leicht mit der letzten. Das bedeutet mehr Daten pro Platte, was höhere Kapazität und/oder geringere Kosten bedeutet. Dies wird als „Shingled Magnetic Recording“ bezeichnet (SMR), analog zur Überlappung von Dachschindeln.

Natürlich würde sich eine Festplatte, die große Änderungen am Betriebssystem erforderte, nicht sehr gut verkaufen. Also fügten sie Übersetzungsfirmware hinzu und eineCMRCache-Bereich, sodass das SMR-Laufwerk für das Betriebssystem wie ein normales Laufwerk aussieht. Es ist nicht sehr unähnlich dem, was SSD-Anbieter bereits tun.

Der Unterschied besteht jedoch darin, dass Flash schnell ist, sodass SSDs selbst mit der Übersetzungsschicht immer noch viel schneller waren als HDDs. Die Leistung von SMR-HDDs hingegen sinkt drastisch, wenn der CMR-Cache-Bereich erschöpft ist und das Laufwerk neue Schreibvorgänge beim langsamen Überschreiben von Shingles blockieren muss.

Leider haben alle drei verbleibenden HDD-Anbieter beschlossen, diese Technologie in ihre Produktpalette einzubauen, ohne die Leute darüber zu informieren. Anstatt also eine bewusste Entscheidung treffen zu können, ob sie im Gegenzug für etwas geringere Kosten pro Speichereinheit einen Leistungsabfall in Kauf nehmen oder nicht, erhielten die Leute diese Laufwerke, ohne es zu wissen. Unter dem Druck der Medien veröffentlichten sie schließlich die Informationen darüber, welche Laufwerksmodelle SMR waren, aber den Kunden ist dies immer noch nicht klar.

Da alle drei großen Festplattenanbieter dies getan haben, kann man die Übeltäter nicht einfach boykottieren. Die einzige Möglichkeit scheint also darin zu bestehen, von nun an jede Festplatte, die man kauft, sorgfältig zu prüfen.

Obwohl die Kapazität ursprünglich der Grund für SMR war, scheinen die größten Laufwerke seltsamerweise oft noch CMR zu sein, während SMR hauptsächlich bei Laufwerken mit einer Kapazität im niedrigen einstelligen Terabyte-Bereich zu finden ist.

verwandte Informationen