P50: Debian läuft auf SATA-HDD sehr langsam

[DaffyC64]

Hallo zusammen,

ich habe ein ThinpPad P50 im Einsatz.
In dieses habe ich zusätzlich zu den beiden M.2 NVMe SSDs eine 2,5" Zoll SATA HDD mit dem passendem Adapter verbaut.
Unter Debian Buster (10.7) ist diese Platte sehr langsam (Transferrate bei ca. 35 MB/s). Unter Windows läuft die Platte ganz normal und bringt die Geschwindigkeit, die der Hersteller angegeben hat (Transferrate 137 MB/s).
Laut Datenblatt des Herstellers sind bis zu 140 MB/s Transferrate drin.

Habt ihr eine Idee woran das liegen kann?

Mein P50 hat folgende Hardware-Konfiguration:

CPU: Intel Core i7-6820HQ vPro
GPU: NVIDIA Quadro M2000M - 4GB GDDR5-VRAM
RAM: 32GB DDR4 im Dual-Channel Betrieb (alle 4 Slots belegt)
(Geschwindigkeit hab ich jetzt nicht parrat - sind zwei Paar RAM Riegel mit unterschiedlichen Geschwindigkeiten)

Folgende Massenspeicher sind verbaut:
2x M.2 NVMe SSD von WD mit je 512GB konfiguriert als RAID0 Verbund (Windows 10 Pro x64 ist auf dem Volume installierz)
1x SATA-III 2,5" HDD mit 2TB (installiertes Debian Buster 10.7 x64 mit unverschlüsseltem LVM)

Die HDD hat folgende Partitionierung unter Debian:

(GPT und UEFI)
sda1 - 512MB - ESP - /boot/efi
sda2 - 512MB - ext2 - /boot
sda3 - 400GB - lvm2 (unverschlüsselt) (separate LV's für root, home, var und swap)
sda4 - 1,6TB - fat32 - /mnt/transfer (soll später auf NTFS) formartiert werden

Beide Systeme wurden frisch aufgesetzt. Die Partitionierung der HDD habe ich aus dem Debian Setup heraus gemacht.
Den Test unter Windows habe ich mit CrystalDiskInfo gemacht.
Unter Debian habe ich mit dd if=/dev/urandom of=/home/tmp & Last erzeugt und mit iotop ausgelesen.

Ursprünglich habe ich das LVM mit dem Debian Setup verschlüsselt. Verschlüsselt war die Datenrate noch etwas langsamer. Ich dachte erst, dass es an der Verschlüsselung liegt und habe Debian nochmal ohne Verschlüsselung installiert.
Allein die Installation (USB 3.0 Stick) hat schon knapp 2 Stunden gebraucht.

Außerdem habe ich im BIOS das RAID abgeschaltet (von RAID-Mode auf AHCI-Mode) und diesen Test unter Debian nochmal vollzogen. Ohne RAID war die HDD immer noch bei 35MB/s.
Mit dmesg habe ich nach Warnings und Erros gegrept und nichts gefunden.
"Grepe" ich nach SATA, wird mir der Status bei aktiviertem RAID mit RAID angezeigt. Bei deaktiviertem RAID im BIOS wird hier AHCI angezeigt
Ein grep nach sda in dmesg teilt mir nur mit, dass die Partitonen korrekt eingehängt sind.
Das AHCI-Modul im Kernel ist aktiv.

Bei der Geschwindigkeit, habe ich das Gefühl, dass die HDD mit einem langsamem PATA-Modus läuft (Fallback weil SATA-Treiber nicht richtig funktioniert?).

Braucht ihr noch weitere Infos zu meinem System? Soll ich euch irgendwelche anderen Infos aus dem Debian zur Verfügung stellen?

Danke im vorraus schonmal für eure Hilfe

Viele Grüße,
DaffyC64

 

[hikaru]

Lass mich das Szenario mal zerlegen:

1. Du hast eine 2TB-HDD verbaut. Die gibt es prinzipiell in zwei Varianten:
A: 7mm Höhe, zwei Platter mit SMR
B: 9,5mm Höhe, drei Platter ohne SMR

Schreibraten sind auch bei HDDs geringer als Leseraten. Daher beziehen sich "Transferraten" aus Marketinggründen ohne weitere Angabe immer auf die Leserate.
SMR geht je nach Situation stark auf die Schreibgeschwindigkeit.
Ich würde dir daher empfehlen, Leseraten zu messen, nicht Schreibraten, wenn du Vergleiche zu Hersteller-"Transferraten" anstelen möchtest - insbesondere, aber nicht nur bei einer SMR-HDD.

2. Du testest mit dd ohne Parameter bs. Dabei nimmt dd aus historischen Gründen standardmäßig eine Block Size von 512 Byte an. Heutige HDDs haben 4k-Sektoren. Du beschreibst also jeden Sektor acht mal, was auf die Performance geht. Die Block Size in dd sollte daher immer der Sektorengröße der HDD bzw. der Flashzellengröße der SSD entsprechen oder ein ganzzahliges Vielfaches davon sein. Du könntest nun also bs=4k angeben oder du bist faul und gewöhnst dir einfach an, dd immer mit bs=1M aufzurufen. Damit bist du auf der sicheren Seite.

3. Du verrätst leider nichts über den Füllstand der HDD. HDDs werden zum Ende hin langsamer. Wenn etwas "hinten" auf die HDD geschrieben werden muss, ist das also langsamer, sollte aber für sich genommen nicht unter 50% der Schreibrate am Anfang sinken.
Außerdem sind HDDs für Fragmentierung anfällig (wenn auch dank schlauerer Dateisysteme und HDD-Firmwares nicht mehr so sehr wie in den 90ern als "Defragmentierung" ein beliebter Volkssport war). Das wird insbesondere im Zusammenhang mit SMR merklich, falls deine HDD schon vor dem Test stark fragmentiert ist.
Auf vielen Dateisystemen bricht außerdem die Schreibrate bei hohem Füllstand massiv ein. Ich hatte mal ein ext4 mit 90% Füllstand auf einer HDD ohne SMR die normalerweie rund 140MB/s schreibend schaffte, dessen Schreibrate schlagartig auf ca. 1MB/s runter ging.

4. Abgesehen davon, dass du statt eines Lesetests einen Schreibtest machst (der bei einer non-SMR-HDD trotzdem nicht so langsam sein sollte) ist es zumindest seltsam, dass deine Datenquelle /dev/urandom ist. /dev/urandom ist unter Umständen "CPU-locked"*. Im Vergleich zu den Schreibraten einer HDD sollte das nicht ins Gewicht fallen, aber falls du nebenher ein Video transcodierst, könnte das trotzdem auf den Durchsatz gehen.

5. Ein verschlüsseltes LVM auf einer HDD hat auf jeden Fall einen Flaschenhals in der Random-Read/-Write-Rate der HDD**, da bei Verschlüsselung alle Zugriffe auf Hardawre-Ebene Random-Zugriffe sind. Wie sich ein unverschlüsseltes LVM hier verhält weiß ich ehrlich gesagt nicht. Ich vermute aber, dass es sich ähnlich wie eine Installation ohne LVM verhält und der Overhead vernachlässigbar ist.

Vorläufiges Fazit:
Wenn du eine SMR-HDD hast, dann vermute ich darin die Ursache des Problems, in Kombination mit den 512Byte-Blöcken von dd. Mach mal einen Lesetest:

dd if=/dev/sdX of=/dev/null bs=1M

oder einfacher:

cat /dev/sdX > /dev/null

oder wenn du dir das zusätzliche iotop sparen und direkt eine schicke Übertragungsrate sehen willst:

pv < /dev/sdX > /dev/null

(Das Paket "pv" muss nachinstalliert werden.)


*) nicht zu verwecheln mit /dev/random, das in jedem Fall "Entropy-locked" ist
**) Bei allen vorherigen Betrachtungen ging es um die sequenziellen Raten, welche höher liegen.

 

[mcb]

Versuche mal

sudo hdparm -tT /dev/sda

zum messen.

Die Verschlüsselung sollte auf der Kiste nicht ins Gewicht fallen.

 

[hikaru]

Versuche mal

sudo hdparm -tT /dev/sda

zum messen.

Nur zur Info:
Das misst direkt auf Hardwareebene. Je nachdem ob man Betriebssystemeffekte mitmessen möchte oder nicht, kann das gewollt oder ungewollt sein.

Die Verschlüsselung sollte auf der Kiste nicht ins Gewicht fallen.

Das ist in Bezug auf die CPU richtig, weil diese AES-NI beherrscht. In Bezug auf den Datenträger bleibt aber festzuhalten, dass Verschlüsselung jeden Zugriff in einen Random-Zugriff verwandelt und sich der Datenträger dann entsprechend verhält.

 

[mcb]

Ja mit hdparm könnte man mal schauen ob es an der Partitionierung oder Software liegt, oder ?

AES macht die CPU mit deutlich mehr als 200 MB/s, also nicht der Flaschenhals.

 

[hikaru]

Ja mit hdparm könnte man mal schauen ob es an der Partitionierung oder Software liegt, oder ?

Das kommt darauf an, wie du hier das "oder" verwendest.
Mit hdparm läst sich eine Abgrenzung zwischen Hardware einerseits und Partitionierung/Software andererseits machen. Aber hdparm taugt nicht um zwischen Partitionierung und Software zu trennen.

Daftys dd-Kommando hat eine Datei auf das Dateisystem seiner Festplatte geschrieben. D.h. in sein Ergebnis gehen die hardwarebedingte Datenrate der HDD, mögliche betriebssystembedingte Effekte (z.B. eine verringerte Datenrate aufgrund einer ausgelasteten CPU) und dateisystembedingte Effekte (z.B. Füllstand, Fragmentierung) ein.
Die Kommandos aus meinem Beitrag arbeiten alle auf Geräteebene der HDD, nicht auf Dateisystemebene. Hier gehen also nach wie vor Hardware- und Betriebssystemeffekte ein, aber keine Dateisystemeffekte.
hdparm sendet nur noch den Befehl für die Geschwindigkeitsmessung an die HDD. Alles andere läuft dann innerhalb der Firmware der HDD ab und ist unabhängig von Betriebssystemeffekten und Dateisystemeffekten.

 

[ach]

rein von der Historie betrachtet: passt das Alignment?

 

[DaffyC64]

Hallo zusammen,

danke für eure kompetenten Antworten.

Die HDD war nicht verschlüsselt. Ursprünglich war sie es. Ich dachte aus diesem Grund ist sie zu langsam und habe das Debian neu unverschlüsselt aufgesetzt.
Allerdings brachte das von der Geschwindigkeit keinen Mehrwert.

@hikaru
Ja stimmt hätte mir auffallen müssen. Das ist mir jetzt schon ein wenig peinlich als ITler.... Naja das ich mich das letzte mal mit Hardware so intesiv beschäftigt habe ist ewig her. Hatte das nicht mehr auf dem Schirm.
Es ist eine 7mm Platte mit SMR.

Ich habe die Leseraten jetzt mit deinem dd Kommando geprüft. bs=1M ist tatsächlich etwas schneller, aber nur marginal.
Ich habe hier durchschnittliche Leseraten von 123 MB/s unter Windows sind es 134 MB/s.
Es scheint also total in Ordnung zu sein. Ich glaube einfach, dass ich indirekt etwas SSD verwöhnt war/bin.

Die HDD ist komplett leer, außer das frisch installierte Debian.
Der Fakt, dass der Gerät bei hohem Füllstand deutlich langsamer wird, und urandom CPU-locked sein kann, war so nicht bekannt. Danke für den Einwurf.

@mcb
Tut sie nicht. Ich habe das Debian nochmal mit Verschlüsselung installiert und mit kiarus dd Befehl getestet.
Da ist in der Leserate so gut wie kein Unterschied erkennbar.

@ach

Laut gdisk geht die erste Partition bei Sektor 2048. Wenn ich das, was ich damals in der Berufsschule gelernt habe noch richtig im Kopf habe, sollte das so richtig sein und das Alignment passen.
Laut Datenblatt des Herstellers hat die Platte 512 (logisch) bzw. 4096 (physikalisch) Byte pro Sektor.

 

[mcb]

Hast du mal überlegt Windows nicht als Raid laufen zu lassen. Könntest dann Debian auf die 2te SSD packen.....

 

[Gummiente]

Ich glaube es wurde die Leistungsfähigkeit der Zufallszahlengenerator gemessen und nicht der HDD.

Kopiere man zwischen SSD und HDD hin und her. Da sollte realistischere Übertragungsraten ablesbar sein.

 

[DaffyC64]

@mcb
Das hatte ich vorher so. Ich brauche die Leistung und vorallem den Platz unter Windows. Allerdings brauche ich auch ein Linux.
Ich hätte Debian und Windows zusammen auf das RAID gepackt und die HDD als Datengrab genutzt. Eventuell hätte ich noch Home auf die HDD ausgelagert.
Allerdings habe ich Debian und auch Grub nicht bebringen können, das RAID zu nutzen. Debian sieht das RAID nicht.

@Gummiente
Habe ich gemacht. Unter Windows ist alles Tutti. Die Schreib- und Leserate stimmt.