[gelöst - PEBKAC] HDD liefert nur noch 1MB/s

[hikaru]

Hallo,

in meinem Desktoprechner (Stretch) laufen zwei 3,5"-4TB-HDDs. Beide wurden aus externen "HGST-Touro"-Gehäusen ausgeschlachtet und sie haben Nettolaufzeiten von ca 4-6 Monaten. Auf der einen steht "Hitachi", auf der anderen "HGST". Da das der selbe Verein ist und die HDDs auch sehr ähnliche Daten haben vermute ich, dass es sich im Grunde um (nahezu) identische Modelle handelt.

Ich habe etwa seit dem Update auf linux-image-4.9.0-9-amd64 das Problem, dass die HGST nur noch 1MB/s an Übertragungsrate liefert (mit dd bzw. pv direkt auf dem Device, also ohne Dateisystemeinfluss). Die Hitachi liefert weiterhin deutlich über 100MB/s. Abgesehen von der geringen Übertragungsrate stelle ich aber keine offensichtlichen Probleme fest.

Ich glaube allerdings nicht wirklich, dass es am Kernel liegt, denn mit linux-image-4.9.0-7-amd64 und linux-image-4.9.0-8-amd64, sowie linux-image-4.19.0-0.bpo.4-amd64 auf dem selben System lässt sich das Problem reproduzieren. Auch eine testweise Deinstallation von intel-microcode (Nebeneffekt von "ZombieLoad"?) brachte keine Besserung.
Andererseits hatte ich gestern einen Jessie-USB-Stick in der Schublade gefunden, mit dessen System ich auf beiden HDDs über 100MB/s erreichte.

Die SATA-Kabel der HDDs habe ich schon untereinander getauscht, es bleibt weiterhin die HGST langsam und die Hitachi schnell. Ich sehe weder in dmesg noch in journalctl auffällige Meldungen (Logs liefere ich gern nach, ich weiß nur nicht wonach ich schauen soll).
Auffällig ist, dass smartctl -t short auf der HGST nach 10% offenbar still abbricht. So habe ich keine aktuellen auswertbaren SMART-Werte. smartd lief durchgehend, die Historie zeigte keine Probleme.

Es wird wahrscheinlich darauf hinauslaufen, die HDD zeitnah auszutauschen, aber mich würde die eigentliche Ursache des Problems interessieren. Hat schon mal jemand so ein Problem gehabt? "Langsame Übertragungsrate" ohne Logzeile ist ein schlechter Suchbegriff.

[MSfree]

Eventuell ist das ein Konflikt zwischen logischer und physischer Sektorgröße.
Heutige Platte haben 4kB Sektoren, können aber auch logisch mit 512 Byte Sektoren adressiert werden. Wenn die Partitionsgrenzen nicht auf volle 4kB-Grenzen fallen, kann das zu Problemen mit der Geschwindigkeit führen.

Code: Alles auswählen

fdisk -l /dev/sdX

zeigt die logische und physische Sektorgröße an.

[schorsch_76]

Das hört sich für mich wie eine Regression an. Jessie Stick geht, Stretch mit aktuellem Kernel ist langsam.

Du könntest auch mal den Kernel vom Jessie Stick auf deine Platte packen und davon booten.

Ich würde hier beide Versionen mit git bisect und dem Treiber Verzeichnis beharken. Wenn du bisect das Verzeichnis gibt's, indem der Treiber zu finden ist, schränkst du die Anzahl der Commits sehr deutlich ein.

[1] https://git-scm.com/docs/git-bisect

[hikaru]

Code: Alles auswählen

fdisk -l /dev/sdX

zeigt die logische und physische Sektorgröße an.

Kann ich gerne nachliefern. Aber darauf achte ich seit Jahren bei der Einrichtung und ich meine, mir wäre das bei den Tests am Wochenende aufgefallen. Außerdem sollte das Alignment bei streng sequenziellen Zugriffen (dd, pv) auch egal sein.
Bis vor ein paar Wochen lief die HDD ja auch noch mit ordentlicher Geschwindigkeit.

[hikaru]

hdparm:

Code: Alles auswählen

# hdparm -i /dev/sdb

/dev/sdb:

 Model=HGST HMS5C4040ALE640, FwRev=MPAOA580, SerialNo=PL1331LAGL16GH
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=unknown, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=7814037168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

# hdparm -i /dev/sdd

/dev/sdd:

 Model=Hitachi HDS5C4040ALE630, FwRev=MPAOA3B0, SerialNo=PL2311LAG2TP4J
 Config={ HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs }
 RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=56
 BuffType=DualPortCache, BuffSize=25060kB, MaxMultSect=16, MultSect=off
 CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=7814037168
 IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
 PIO modes:  pio0 pio1 pio2 pio3 pio4 
 DMA modes:  mdma0 mdma1 mdma2 
 UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6 
 AdvancedPM=yes: disabled (255) WriteCache=enabled
 Drive conforms to: unknown:  ATA/ATAPI-2,3,4,5,6,7

 * signifies the current active mode

fdisk:

Code: Alles auswählen

# fdisk -l /dev/sdb
Disk /dev/sdb: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 6DB9FB2E-45D5-417A-8C7D-EF0D5AB32953

Device          Start        End    Sectors  Size Type
/dev/sdb1        2048 7604322303 7604320256  3,6T Linux filesystem
/dev/sdb2  7604322304 7814035455  209713152  100G Linux filesystem
# fdisk -l /dev/sdd
Disk /dev/sdd: 3,7 TiB, 4000787030016 bytes, 7814037168 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: A1EC1B4A-4712-4E20-BE58-A515FEEF9B74

Device     Start        End    Sectors  Size Type
/dev/sdd1   2048 7814035455 7814033408  3,7T Linux filesystem

Ein Alignment-Problem besteht also nicht.

pv:

Code: Alles auswählen

# pv < /dev/sdb > /dev/zero 
^C38MiB 0:00:04 [1,17MiB/s] [>             ]  0% ETA 32:20:43:19
# pv < /dev/sdd > /dev/zero 
^C11MiB 0:00:04 [ 129MiB/s] [>             ]  0% ETA 8:17:27

Die "HGST" (sdb) ist furchtbar langsam.

Ich habe auch noch einen Buster-Stick erstellt. Wie auf dem Jessie-Stick habe ich hier normale Übertragungsraten >100MB/s auf beiden HDDs. Eine Kernel-Regression würde ich daher ausschließen. Irgendwas anderes muss an meinem System seltsam sein. Wo setzt man da an?
Aus Verzweiflung hier noch dmesg: 40727

[MSfree]

Verzweiflungstip:

Hast du mal ein anderes SATA-Kabel ausprobiert?

[hikaru]

Des Rätsels Lösung:
Die HGST überschritt kürzlich einen Füllstand von 90%. Dass ext4 das tendenziell nicht mag war mir bekannt, aber dass es sich so krass auswirkt, hätte ich nicht erwartet. Die HDD rödelte panisch vor sich hin, was mir aber erst in einem Moment ohne Umgebungsgeräusche auffiel. (Leise Rechner sind Mist! Vor 20 Jahren hätte ich das sofort aus dem Nebenzimmer heraus erkannt! )

Nachdem ich etwa 50GB Daten gelöscht hatte, beruhigte sich die Situation. Im Moment verschiebe ich ein paar 100GB von der HGST auf die Hitachi (mit rund 80MB/s).
Die Stick-Systeme bekamen davon wohl Nichts mit, weil dort die HDD nicht gemountet war.

Xfces Füllstandswarnung habe ich gleich mal angepasst.