HDD liest nur mit 500kb/s - SmartWerte aber OK...

[lons]

Hallo

Eine meiner Hdd's im Fileserver wurde schlagartig extrem langsam...

Supermicro x11sae-m
Xeon E3-1225 v5
Problem Hdd WD WD100EZAZ 10TB
FS: EXT4
BS: Debian

Deswegen versuche ich gerade 8TB um zu kopieren...
Je nach Datei dauert es ein bisschen bis die Leserate abfällt.
Kleine Dateien bis 5MB von Anfang an, größere > 2 GB kopieren die ersten ca. 500MB mit bis zu 90MB/s und fallen dann auf max. 500kb/s ab...
Von jeder anderen Platte kopiere ich ganz normal...
Gestestet wurde Lokal mittels Midnight Commander - dieser meldet gerade 609 Stunden Kopierzeit für 500GB...
Wie es der Teufel so will, ist dies die einzige Platte im Server ohne Backup.
Ein "fsck.ext4 /dev/sdh1" verläuft fehlerfrei

Smart Werte unauffällig: Hängt gerade am Win PC

          Model : WDC WD100EZAZ-11TDBA0
        Firmware : 83.H0A83
   Serial Number : JEKDY9UZ
       Disk Size : 10000,8 GB (8,4/137,4/10000,8/10000,8)
     Buffer Size : Unbekannt
     Queue Depth : 32
    # of Sectors : 19532873728
   Rotation Rate : 5400 RPM
       Interface : USB (Serial ATA)
   Major Version : ACS-2
   Minor Version : ATA8-ACS version 4
   Transfer Mode : SATA/300 | SATA/600
  Power On Hours : 18885 Std.
  Power On Count : 56 mal
     Temperature : 39 C (102 F)
   Health Status : Gut
        Features : S.M.A.R.T., APM, 48bit LBA, NCQ
       APM Level : 00FEh [OFF]
       AAM Level : ----
    Drive Letter :

-- S.M.A.R.T. --------------------------------------------------------------
ID Cur Wor Thr RawValues(6) Attribute Name
01 _78 _78 _16 000000000386 Lesefehlerrate
02 130 130 _54 00000000006C Datendurchsatz-Leistung
03 156 156 _24 000901BD0191 Mittlere Anlaufzeit
04 100 100 __0 000000000263 Start/Stopp-Zyklen der Spindel
05 100 100 __5 000000000000 Wiederzugewiesene Sektoren
07 100 100 _67 000000000000 Suchfehler
08 128 128 _20 000000000012 Güte der Suchoperationen
09 _98 _98 __0 0000000049C5 Betriebsstunden
0A 100 100 _60 000000000000 Misslungene Spindelanläufe
0C 100 100 __0 000000000038 Geräte-Einschaltvorgänge
16 100 100 _25 000000000064 Herstellerspezifisch
C0 _99 _99 __0 0000000004EA Ausschaltungsabbrüche
C1 _99 _99 __0 0000000004EA Laden/Entladen-Zyklen
C2 166 166 __0 003000190027 Temperatur
C4 100 100 __0 000000000000 Wiederzuweisungsereignisse
C5 100 100 __0 000000000000 Aktuell ausstehende Sektoren
C6 100 100 __0 000000000000 Nicht korrigierbare Sektoren
C7 200 200 __0 000000000000 UltraDMA-CRC-Fehler

Was könnte ich sonst noch checken bzw. versuchen?

Danke, Lons

 

[butcher1de]

Der Klassiker : Probiere mal ein neues Daten Kabel.

 

[Holt]

Kleine Dateien bis 5MB von Anfang an, größere > 2 GB kopieren die ersten ca. 500MB mit bis zu 90MB/s und fallen dann auf max. 500kb/s ab...

Auf welche Platte wird denn kopiert? Deren S.M.A.R.T. Werte wären auch interessant. Außerdem weiß ich zwar nicht wie der Midnight Commander arbeitet, der Windows Explorer nutzt aber sonst unbelegtes RAM als Puffer und zeigt die Kopiergeschwindigkeit auf Basis des gelesenen Datenvolumens an, weshalb diese am Anfang der Lesegeschwindigkeit entsprechen und sobald der Puffer voll ist, dann auf die Schreibgeschwindigkeit abfallen, sofern das Ziel die Daten eben nicht so schnell wegschreiben kann, wie die Quelle die Daten liefert.

Smart Werte unauffällig

Naja, die Lesefehler sind schon ein wenig auffällig:

01 _78 _78 _16 000000000386 Lesefehlerrate

Aber es gibt keine ausstehenden Sektoren, von daher dürfte dies kaum der Grund sein.

Der Klassiker : Probiere mal ein neues Daten Kabel.

Unsinn, denn es gab nie Fehler bei der Kommunikation mit dem Host Controller, wie man hier sieht:

C7 200 200 __0 000000000000 UltraDMA-CRC-Fehler

Außerdem ist es eine USB Platte:

Interface : USB (Serial ATA)

 

[lons]

Die Empfänger Hdd:
Wobei ich schon auf 4 verschiede Hdds sichern versucht habe - immer mit max. 500kb/s...

=== START OF INFORMATION SECTION ===
Model Family:     Western Digital Ultrastar He10/12
Device Model:     WDC WD100EZAZ-11TDBA0
Serial Number:    JEKEPUBZ
LU WWN Device Id: 5 000cca 267f0813d
Firmware Version: 83.H0A83
User Capacity:    10,000,831,348,736 bytes [10.0 TB]
Sector Sizes:     512 bytes logical, 4096 bytes physical
Rotation Rate:    5400 rpm
Form Factor:      3.5 inches
Device is:        In smartctl database [for details use: -P show]
ATA Version is:   ACS-2, ATA8-ACS T13/1699-D revision 4
SATA Version is:  SATA 3.2, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is:    Sun Sep 19 02:20:25 2021 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
AAM feature is:   Unavailable
APM level is:     128 (minimum power consumption without standby)
Rd look-ahead is: Enabled
Write cache is:   Enabled
DSN feature is:   Unavailable
ATA Security is:  Disabled, frozen [SEC2]
Wt Cache Reorder: Enabled


SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME          FLAGS    VALUE WORST THRESH FAIL RAW_VALUE
  1 Raw_Read_Error_Rate     PO-R--   100   100   016    -    0
  2 Throughput_Performance  --S---   130   130   054    -    108
  3 Spin_Up_Time            POS---   153   153   024    -    430 (Average 431)
  4 Start_Stop_Count        -O--C-   100   100   000    -    719
  5 Reallocated_Sector_Ct   PO--CK   100   100   005    -    0
  7 Seek_Error_Rate         -O-R--   100   100   067    -    0
  8 Seek_Time_Performance   --S---   128   128   020    -    18
  9 Power_On_Hours          -O--C-   098   098   000    -    18846
 10 Spin_Retry_Count        -O--C-   100   100   060    -    0
 12 Power_Cycle_Count       -O--CK   100   100   000    -    51
 22 Helium_Level            PO---K   100   100   025    -    100
192 Power-Off_Retract_Count -O--CK   096   096   000    -    5174
193 Load_Cycle_Count        -O--C-   096   096   000    -    5174
194 Temperature_Celsius     -O----   175   175   000    -    37 (Min/Max 25/41)
196 Reallocated_Event_Count -O--CK   100   100   000    -    0
197 Current_Pending_Sector  -O---K   100   100   000    -    0
198 Offline_Uncorrectable   ---R--   100   100   000    -    0
199 UDMA_CRC_Error_Count    -O-R--   200   200   000    -    0
                            ||||||_ K auto-keep
                            |||||__ C event count
                            ||||___ R error rate
                            |||____ S speed/performance
                            ||_____ O updated online
                            |______ P prefailure warning

 

[Holt]

Die ist in Ordnung, wie wird denn genau kopiert? Es scheinen ja nicht beide Platten lokal am PC angeschlossen zu sein, sondern die Zielplatte steckt ja wohl in den Fileserver, aber wie ist der genau angebunden? Und wo ist die Quellplatte angeschlossen? Auch am Fileserver und dann wird aber über den PC kopiert oder wie? Da würde ich mal zuerst schauen, denn die Platten scheinen mir hier nicht der Grund für die geringe Geschwindigkeit zu sein.

 

[lons]

Die Langsame habe ich nur kurz ausgebaut und an den Windows PC gehängt um zu sehen wie sie hier tut - leider nichts besser.
Danach hab ich sie über USB3 an den Server gehängt - ebenfalls nicht schneller.
Nun ist sie wieder über Onboard Sata im Server.
Kopiert wird mittels Midnight Commander direkt Lokal am Server, angemeldet über Putty.
Ich hab's auch mit rsync und ddrescue versucht - ganz egal... ich komme nie über 500kb/s.
Allerdings betrifft dies nur diese eine Platte.
Kann ich sonst was Prüfen? Dateisystem scheint ja laut "fsck.ext4" in Odnung zu sein.

 

[Holt]

Also sind beide intern an SATA am Server und es wird lokal auf dem Server kopiert und trotzdem werden nur 500kb/s (also Kilobit) erreicht? Dies ist sehr seltsam. Ich nehmen mal an, es gibt auch keine Datenverschlüsselung oder sowas?

Beitrag automatisch zusammengeführt: 19.09.2021

Die Langsame habe ich nur kurz ausgebaut und an den Windows PC gehängt um zu sehen wie sie hier tut - leider nichts besser.

Hattest Du sie bei der Gelegenheit auch mal gebencht? Z.B. mit CrystalDiskMark? Dies wäre mal interessant, auch wenn Du sie dazu wohl neu formatieren oder einen ext4 Treiber installieren musst.

Ich hab's auch mit rsync und ddrescue versucht

Welche Blocksize (bs=) hast Du dabei verwendet?

ich komme nie über 500kb/s.

Wo liest Du die eigentlich ab?

Dateisystem scheint ja laut "fsck.ext4" in Odnung zu sein.

Welchen Clustersize hat das Filesystem?

 

[lons]

Keine Verschlüsselung
Benchmark hab ich leider keine gemacht
Die Geschwindigkeit gibt mir rsync mittels --progress --stats aus, bzw. Midnight Commander zeigt die momentane und durchschnittliche Geschwindigkeit an.
--block-size= von klein bis max alles mögliche versucht
Clustersize : 4096

Ich hab keinen Plan mehr...

 

[butcher1de]

@Allwissender Holt Könnte der Cache der Platte oder ein anderes Bauteil defekt/zu heiß sein und kann man das irgendwo sehen? Mich irritiert das sie erst mit normalen werten kopiert und dann auf 500 kb herunterfällt.

37°C für den Controller ist ja vollkommen in Ordnung.

 

[Holt]

Könnte der Cache der Platte oder ein anderes Bauteil defekt/zu heiß sein

Nein, denn das ist ja kleiner DRAM Baustein und der wird nicht so heiß und selbst wenn oder wenn er defekt wäre, so ist es das DRAM des Controller, in Wahrheit wird nur ein Teil davon wirklich als Datencache genutzt (Hitachi hat früher sogar angegeben wie viel, heute wird einfach immer die Größe des RAMs als Cache angegeben) und die Platte würde nicht mehr funktionieren. Der nächste Ansatz wäre aber auch bei mir zu schauen, ob der Cache überhaupt aktiv ist, aber selbst dann scheinen mir die Werte zu gering, zumal bei großen Dateien.

Mich irritiert das sie erst mit normalen werten kopiert und dann auf 500 kb herunterfällt.

Das kann am Puffern liegen. Wir müssten erstmal schauen, ob das Problem bei der Quell- oder der Zielplatte liegt. Ich würde mal schauen wie schnell Dateien von der Quellplatte gelesen werden können, dazu einige der großen einfach mal mit dd (bs beachten) nach /dev/zero kopieren und dann würde ich mal schauen wie schnell die Zielplatte schreiben kann, indem ich mit dd einfach mal aus /dev/zero (bs und count entsprechend einstellen) eine größere Datei darauf anlegen würde. Auch wenn es schon mit 4 Empfänger HDDs versucht wurde, so kann es am Mountoptionen liegen, z.B. am Journaling.

Die Platten hängen doch sicher direkt an den SATA Ports des C236, oder ist da noch ein Zusatzcontroller z.B. ein SAS HBA / SAS RAID Controller verbaut?

 

[butcher1de]

Die Langsame habe ich nur kurz ausgebaut und an den Windows PC gehängt um zu sehen wie sie hier tut - leider nichts besser.
Danach hab ich sie über USB3 an den Server gehängt - ebenfalls nicht schneller.
Nun ist sie wieder über Onboard Sata im Server.

Hat er schon probiert. Daher meine Vermutung mit der Temperatur. Der TE soll mal während des Kopierens (wenn die 500 KB wieder anfangen) mal nach der Temperatur schauen.

 

[Holt]

Daher meine Vermutung mit der Temperatur.

Aber anderes als SSDs werden HDDs dann nicht langsamer, dies sieht man ja auch an den ganzen USB Platten, die werden ja auch gerne mal sehr warm und drosseln trotzdem die Geschwindigkeit nicht. Das würde bei denen auch nichts bringen, da sie ja dann trotzdem laufen und die Leistungsaufnahme nicht nennenswert geringer wäre, wenn sie künstlich die Geschwindigkeit reduzieren, also einfach einfach die Platte mal eine oder zwei Umdrehungen ohne Datenübertragung machen lassen würden.

 

[lons]

Danke für die tolle Unterstützung
Platten hängen alle direkt am Mainboard, ohne Zusatz Controller.
Die Temperatur bleibt konstant bei 36°

Schreiben sieht schon mal super aus:

dd if=/dev/zero of=/srv/dev-disk-by-uuid-e1e83b6e-f09d-4234-a997-1f2f89cd3abb/probe.leer bs=3M count=1024
1024+0 Datensätze ein
1024+0 Datensätze aus
3221225472 bytes (3,2 GB, 3,0 GiB) copied, 15,3378 s, 210 MB/s

Lesen, leider katastrophal, kopieren hab ich nach ca. 15 min abgebrochen.
In der Zeit hat er gerade mal 30MB von 3GB gelesen...

dd if=/srv/dev-disk-by-uuid-e1e83b6e-f09d-4234-a997-1f2f89cd3abb/Videoschnitt/H265/Winter 2020.mp4 of=dev/zero bs=1M status=progress
30408704 bytes (30 MB, 29 MiB) copied, 891,838 s, 34,1 kB/s
^C

dd if=/srv/dev-disk-by-uuid-e1e83b6e-f09d-4234-a997-1f2f89cd3abb/Videoschnitt/H265/Winter 2020.mp4 of=dev/zero bs=3M status=progress
34603008 bytes (35 MB, 33 MiB) copied, 174,653 s, 198 kB/s
^C

Die ersten 25 Sekunden liest er mit knapp 100MB/s, dann der komplette Schnitt runter auf unter 100kb/s.

Und einmal die bereits Kopierte Datei von einer anderen Platte lesen:

dd if=/srv/dev-disk-by-id-ata-WDC_WD100EZAZ-11TDBA0_JEKEPUBZ-part1/Videoschnitt/H265/Winter 2020.mp4 of=dev/zero bs=1M
3038+1 Datensätze ein
3038+1 Datensätze aus
3186147716 bytes (3,2 GB, 3,0 GiB) copied, 16,1377 s, 197 MB/s

 

[Holt]

Lesen, leider katastrophal, kopieren hab ich nach ca. 15 min abgebrochen.

Das ist sehr seltsam, aber ich habe auch keine Idee woran dies nun liegen könnte und würde Dir empfehlen Geduld zu haben und die Dateien zu kopieren, anders bekommst Du die Dateien da ja nicht runter und verlieren möchtest Du sie ja offenbar auch nicht. Lass den Rechner eben einfach laufen. Denke dann daran künftig immer mindestens ein Backup zu haben.

 

[lons]

Ja eh
Murphys Law - Die einzige Platte ohne Backup musste es erwischen
Aber die bekomm ich ja nichtmal auf RMA getauscht, wenns keine Fehler gibt.

Kopieren ist leider keine Option mehr, sie kopiert momentan mit heißen 42kb/s... da dauern 8TB wohl ein paar Jahre...

Das eigenartige ist, Schreiben geht ganz normal. Nur lesen scheitert und ab & zu kopiert er eine Datei mit knapp 50Mb/s...

 

[Holt]

Dann probiere doch mal ob das RAW Device auch so langsam liest, also sowas wie

dd if=//dev/sdx of=dev/null bs=1M count=1000 status=progress

(sdx natürlich entsprechend ersetzen). Wenn sie dann schnell liest, dann liegt es am Filesystem und nicht an der Platte selbst.

 

[lons]

Sieht aus als wäre das Dateisystem defekt:

sdh1:

dd if=/dev/sdh1 of=/dev/null bs=1M count=1000 status=progress
925892608 bytes (926 MB, 883 MiB) copied, 14 s, 66,1 MB/s
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes (1,0 GB, 1000 MiB) copied, 14,5696 s, 72,0 MB/s

direkt sdh:

dd if=/dev/sdh of=/dev/null bs=1M count=1000 status=progress
1046478848 bytes (1,0 GB, 998 MiB) copied, 5 s, 209 MB/s
1000+0 Datensätze ein
1000+0 Datensätze aus
1048576000 bytes (1,0 GB, 1000 MiB) copied, 5,01771 s, 209 MB/s

 

[Holt]

Sieht aus als wäre das Dateisystem defekt

Ob es defekt ist oder was anderes dahinter steckt, kann ich nicht sagen, aber die HDD selbst liefert jedenfalls die zu erwartenden Leseraten. Die S.M.A.R.T. Werte lügen bei HDD eigentlich nie, bei einigen SSDs kommt das schon mal vor und ja, es gibt auch Fälle von gebrauchten HDDs bei denen die S.M.A.R.T. Werte zurückgesetzt werden, aber ich habe noch keinen Fall gesehen in dem eine HDD bei der Werte in Ordnung waren trotzdem einen Defekt hatte.

Allerdings fällt es schon auf, dass die 72 MB/s /dev/sdh1 gegenüber den 209MB/s für /dev/sdh recht gering sind, denn normalerweise lieht zwischen den Leseraten auf den äußersten Spuren und den innersten, nur etwa so Faktor 2. Liegt vielleicht ein Problem mit dem Alignment der Partition vor? Obwohl dies beim Lesen und vor allem bei bs=1M eigentlich kein Problem sein sollte.

 

[lons]

Meinst du so überprüfen?

fdisk -l -u /dev/sdh1

Disk /dev/sdh1: 9,1 TiB, 10000830279680 bytes, 19532871640 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

 

[Holt]

fdisk liest ja nur die Eigenschaften der Platte selbst aus, aber nichts über Partitionen oder Filesysteme darauf.