(gelöst)Raid 1: Schreibgeschwindigkeit extrem langsam

[nyami]

Hallo zusammen,

ich habe einen Server auf dem Nextcloud unter LXC in einem priviligiertem Containerläuft.
Das "nextcloud-data" Verzeichnis ist eingebunden unter /nextcloud-data und grundsätzlich läuft alles.

Lediglich die Zugriffsgeschwindigkeit auf das Raid ist extrem langsam.
Diese lag eben beim Download mit wget bei unter 30kB/sek!!!!!!

Ich freue mich über alle Vorschläge dies abzustellen.

Code: Alles auswählen

mdadm --detail /dev/md127 
/dev/md127:
           Version : 1.2
     Creation Time : Wed Mar  2 18:30:51 2022
        Raid Level : raid1
        Array Size : 3906885440 (3725.90 GiB 4000.65 GB)
     Used Dev Size : 3906885440 (3725.90 GiB 4000.65 GB)
      Raid Devices : 2
     Total Devices : 2
       Persistence : Superblock is persistent

     Intent Bitmap : Internal

       Update Time : Sat Jul 23 18:14:22 2022
             State : active 
    Active Devices : 2
   Working Devices : 2
    Failed Devices : 0
     Spare Devices : 0

Consistency Policy : bitmap

              Name : XXXXX:0  (local to host XXXXX)
              UUID : e165cbc2:6ad2394e:058ceb3c:a03a038b
            Events : 8767

    Number   Major   Minor   RaidDevice State
       0       8       49        0      active sync   /dev/sdd1
       1       8       33        1      active sync   /dev/sdc1

hdparm -T /dev/md127 

/dev/md127:
 Timing cached reads:   11246 MB in  2.00 seconds = 5629.67 MB/sec

Auf dem Server ausserhalb LXC :

Code: Alles auswählen

speedtest-cli 
Retrieving speedtest.net configuration...
Testing from Versatel Deutschland (46.142.158.76)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Deutsche Telekom (Dusseldorf) [18.06 km]: 18.179 ms
Testing download speed................................................................................
Download: 102.42 Mbit/s
Testing upload speed......................................................................................................
Upload: 39.51 Mbit/s

Im LXC-Container:

Code: Alles auswählen

speedtest-cli 
Retrieving speedtest.net configuration...
Testing from Versatel Deutschland (46.142.158.76)...
Retrieving speedtest.net server list...
Selecting best server based on ping...
Hosted by Deutsche Telekom (Dusseldorf) [18.06 km]: 13.563 ms
Testing download speed................................................................................
Download: 102.29 Mbit/s
Testing upload speed......................................................................................................
Upload: 39.81 Mbit/s

Wenn ich im Container einen wget-download direkt ins Datenvereichnis mache wird das alles zur Katastrophe:

Code: Alles auswählen

wget github.com
URL transformed to HTTPS due to an HSTS policy
--2022-07-23 16:25:54--  https://github.com/
Auflösen des Hostnamens github.com (github.com)… 140.82.121.3
Verbindungsaufbau zu github.com (github.com)|140.82.121.3|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html                 [            <=>              ] 267,70K  8,11KB/s    in 37s     

2022-07-23 16:26:35 (7,15 KB/s) - »index.html« gespeichert [274124]

ebenso auf dem Server ausserhalb LXC:

Code: Alles auswählen

wget github.com
URL transformed to HTTPS due to an HSTS policy
--2022-07-23 18:33:02--  https://github.com/
Auflösen des Hostnamens github.com (github.com)… 140.82.121.3
Verbindungsaufbau zu github.com (github.com)|140.82.121.3|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html.1« gespeichert.

index.html.1                                          [                                                                                               <=>          ] 267,70K  8,19KB/s    in 36s     

2022-07-23 18:33:38 (7,44 KB/s) - »index.html.1« gespeichert [274124]

Es scheint also irgendwas mit dem einbinden des Raids zu sein?
Eingebunden ist das Raid über die fstab:

Code: Alles auswählen

UUID=a9aaab7d-b4e0-43c9-8b62-320937dcd674       /shares ext4    auto,nofail,sync,users,rw       0       0

[Livingston]

Eingebunden ist das Raid über die fstab:

Sicher? Warum steht dann die Angabe einer UUID stat /dev/md127 in der fstab?

[nyami]

jep

Code: Alles auswählen

blkid
/dev/sda1: UUID="842B-93F3" BLOCK_SIZE="512" TYPE="vfat" PARTUUID="afa0b0af-aa60-463e-acdf-17afd3463435"
/dev/sda2: UUID="bc8ed19f-e39e-47af-8de9-d0c2997d9d27" BLOCK_SIZE="4096" TYPE="ext4" PARTUUID="a9c97e8f-b094-453e-a991-ba56260db8c2"
/dev/sda3: UUID="ea27a175-aa52-450d-bbcc-4a3e9933b78b" TYPE="swap" PARTUUID="0d73a2ae-8617-40a3-84e1-efab364781e4"
/dev/sdb1: LABEL="backup" UUID="e9ff1883-ba61-4d7c-ab31-eb0429978750" BLOCK_SIZE="4096" TYPE="ext4"
/dev/sdc1: UUID="e165cbc2-6ad2-394e-058c-eb3ca03a038b" UUID_SUB="12997399-2682-70d1-5eac-75b368de5447" LABEL="nuc-sroth:0" TYPE="linux_raid_member" PARTUUID="04d518c2-2e47-5643-bf33-189aeee0c108"
/dev/sdd1: UUID="e165cbc2-6ad2-394e-058c-eb3ca03a038b" UUID_SUB="5b3a4778-5484-4e8f-b9b2-292b13765ce8" LABEL="nuc-sroth:0" TYPE="linux_raid_member" PARTUUID="7e95d2eb-773d-a04f-a54f-aee946909aaa"
/dev/md127: UUID="a9aaab7d-b4e0-43c9-8b62-320937dcd674" BLOCK_SIZE="4096" TYPE="ext4"

[heisenberg]

Was hast Du denn für Platten?

[nyami]

https://www.amazon.de/gp/product/B00UNA ... UTF8&psc=1

[heisenberg]

Ich sehe da nicht, welche Modelle das sind. Kannst Du mittels smartctl oder inxi mal die genauen Plattenbezeichnungen ermitteln?

[nyami]

Leider nur ne Fehlermeldung!

Code: Alles auswählen

smartctl -a /dev/sdc
smartctl 7.2 2020-12-30 r5155 [x86_64-linux-5.10.0-16-amd64] (local build)
Copyright (C) 2002-20, Bruce Allen, Christian Franke, www.smartmontools.org

Read Device Identity failed: scsi error unsupported field in scsi command

A mandatory SMART command failed: exiting. To continue, add one or more '-T permissive' options.

[heisenberg]

Dann wird die USB-SATA Bridge nicht unterstützt.

Die Frage ist, wie denn die allgemeine Schreibgeschwindigkeit des RAIDs ist? Mal ein dd mit 2 GB auf das RAID-FS machen? Verdacht: Das sind SMR Platten.

Alternativ den wget mal auf die interne Platte durchführen?

[nyami]

Wget intern ist ok

Code: Alles auswählen

wget github.com
URL transformed to HTTPS due to an HSTS policy
--2022-07-23 21:17:31--  https://github.com/
Auflösen des Hostnamens github.com (github.com)… 140.82.121.3
Verbindungsaufbau zu github.com (github.com)|140.82.121.3|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 200 OK
Länge: nicht spezifiziert [text/html]
Wird in »index.html« gespeichert.

index.html              [ <=>                ] 267,70K  --.-KB/s    in 0,07s   

2022-07-23 21:17:32 (3,76 MB/s) - »index.html« gespeichert [274124]

[heisenberg]

Es wird wärmer...

Was sagt der dd?

[nyami]

Code: Alles auswählen

dd if=2021_06_03-11_03_11-DSCN1167.JPG of=test
9559+1 Datensätze ein
9559+1 Datensätze aus
4894630 Bytes (4,9 MB, 4,7 MiB) kopiert, 0,0667112 s, 73,4 MB/s

Code: Alles auswählen

dd if=2021_06_03-11_03_11-DSCN1167.JPG of=/shares/nextcloud-data/test/test.jpg

9559+1 Datensätze ein
9559+1 Datensätze aus
4894630 Bytes (4,9 MB, 4,7 MiB) kopiert, 686,827 s, 7,1 kB/s

[nyami]

Ich habe nun meine 3. USB-Platte getestet,die als Backupplatte läuft und:
Geschwindigkeit ist ebenso grottig.

Code: Alles auswählen

dd if=2021_06_03-11_03_11-DSCN1167.JPG of=/backup/test.jpg
^C78+0 Datensätze ein
78+0 Datensätze aus
39936 Bytes (40 kB, 39 KiB) kopiert, 14,7645 s, 2,7 kB/s

Code: Alles auswählen

lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/7p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=uas, 5000M
    |__ Port 3: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
    |__ Port 4: Dev 4, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/9p, 480M
    |__ Port 9: Dev 2, If 0, Class=Wireless, Driver=btusb, 12M
    |__ Port 9: Dev 2, If 1, Class=Wireless, Driver=btusb, 12M

[heisenberg]

Also grundsätzlich würde ich bei Platten nicht mit MB Grösse sondern mit GB grösse Testen.

Also so etwas wie das hier:

Code: Alles auswählen

time dd if=/dev/zero bs=100M count=1 of=/usbfs/test.bin

bzw.

Code: Alles auswählen

time dd if=/dev/zero bs=1G count=1 of=/usbfs/test.bin

Aber so insgesamt scheint sich der Verdacht zu erhärten, dass die Platten nach meinem Verständnis eher als "defekt" einzustufen sind. (Alles was unter 1 MB/s Schreibrate liegt für mich auf jeden Fall. IMO alles was unter 10 MB/s Schreibrate liegt.). Von einer neuen Platte würde ich im linearen Schreiben mal mindestens 100 MB/s erwarten.

Meine Empfehlung wäre also, die Daten von den Platten mal zu sichern und ein ganz normales Dateisystem (ext4) darauf zu erstellen. (Kein RAID!) Danach den obigen Test mehrmals wiederholen. Wenn die Datenrate unter 1 MB/s liegt, würde ich die Platten als defekt reklamieren.

Ansonsten wäre es wirklich hilfreich herauszufinden, welche Festplatte denn da verbaut ist. Das Internet sagt, dass sich Seagate bei dem Produkt die Freiheit nimmt, alles zu verbauen, was der Spezifikation entspricht. D. h. kein festes HDD-Modell für dieses externe "Storage Expansion Desktop".

Hier ist z. B. der Hinweis, dass wie man SMART-Informationen für Festplatten mit dem "UAS"-Treiber bekommt:

https://www.smartmontools.org/ticket/1330

Vielleicht kann man auch das Gehäuse öffnen, um das HDD-Modell zu ermitteln. ( Vorsicht: Evtl. Verlust der Gewährleistung, wenn man da entsprechende Aufkleber entfernt. Wenn es ohne Verlust der Gewährleistung nicht möglich ist, das Gehäuse zu öffnen, würde ich es lassen.)

Nachtrag:

Auf der Amazon Seite von Dir schreibt ein Benutzer, was das für eine Platte ist, die (bei Ihm) verbaut wurde: ST4000DM005 -> Seagate Barracuda 4 TB -> Das ist eine SMR-Platte. Also grundsätzlich für RAID komplett ungeeignet. Ich würde es mit Reklamation versuchen.

[nyami]

Hi,

danke für Deinen Input.
Wenn es die Festplatten waren, dann müsste doch meine Backupplatte wenigstens schneller sein!?

Intenso Memory Case Portable Hard Drive 4TB, tragbare externe Festplatte - 2,5 Zoll, 5400 U/min, 8 MB Cache, USB 3.0 schwarz

Aber auch die ist ja so langsam?

Wieso sind die Platten für Raid ungeeignet? Auf was muss ich denn achten?

Gruß Sven

[heisenberg]

Wieso sind die Platten für Raid ungeeignet?

Festplatten, die mit der Technik SMR arbeiten, sind für parallele Schreibzugriffe ungeeignet. Mehr erfährst Du in der unten verlinkten Diskussion bzw. in den dort verlinkten Artikeln.

Wenn es die Festplatten waren, dann müsste doch meine Backupplatte wenigstens schneller sein!?

Intenso Memory Case Portable Hard Drive 4TB, tragbare externe Festplatte 2,5 Zoll, 5400 U/min, 8 MB Cache, USB 3.0 schwarz. Aber auch die ist ja so langsam?

Das ist zwangsläufig auch eine SMR-Festplatte, weil es keine Nicht-SMR-Platten in 2,5 Zoll mit einer Speicherkapazität von >= 2 TB gibt.

Siehe diese allgemeine Diskussion zum Thema https://debianforum.de/forum/viewtopic.php?p=1306005.

Auf was muss ich denn achten?

Für RAID:

• Grundsätzlich 3,5" Festplatten nehmen
• Nur Festplatten nehmen, deren Festplatten-Modellbezeichnung ausgewiesen ist(Finger weg von externen Geräten ohne Spezifikation der verwendeten Festplatten - also so wie bei Deinen 3 Platten)
• Recherchiere im Internet und stelle sicher, dass die Festplatte CMR/PMR/LMR als Technik zur Datenspeicherung verwendet und keinesfalls SMR.

[MSfree]

4TB, tragbare externe Festplatte - 2,5 Zoll,

Das ist halt eine SMR-Platte. Beim Shingled Magnetic Recording werden nebeneinander liegenden Datenspuren mit Überlappung geschrieben, um die Datendichte zu erhöhen. Im Zweifelsfall müssen beim Schreiben beide Nachbarspuren eingelesen werden und neu geschrieben werden, wenn man die eigentlichen Daten auf die Platte schreiben will. Das macht SMR lahm bis extrem lahm beim Schreiben.

Im Raid ist nun nicht vorhersagbar, welche Platte gerade mit dem Neuschreiben von Nachbarspuren beschäftigt ist. Der RAID-Controller (oder eben der RAID-Algorythmus im Kernel) kann bei größeren Wartezeiten einer Platte diese als nicht reagierend interpretieren und Fehler melden, bzw, die Platte aus dem Verbund hängen.

Auf was muss ich denn achten?

Das Zauberwort heißt CMR (Conventional Magnetic Recording). Als Hinweis am Rande: es gibt keine 2.5"-Platte in CMR mit mehr als 2.5TB Kapazität. 4TB ist also mit absoluter Sicherheit SMR.

[Tintom]

Bevor du die Festplatten reklamierst würde ich zunächst die Option sync aus den Mountoptionen herausnehmen und dann noch einmal testen.

[nyami]

Vielen Dank.

Das entfernen der Sync-Option hat sehr viel gebracht!

Demnächst werde ich dann die Platten tauschen....

[heisenberg]

Das entfernen der Sync-Option hat sehr viel gebracht!

Ja. Der Tip war auch Gold wert! Wie sind denn aktuell die Werte vom dd?

[nyami]

Die Werte liegen bei. Einigen MB. Details reiche ich morgen nach!

[nyami]

dd if=2021_06_03-11_03_11-DSCN1167.JPG of=/shares/nextcloud-data/test/test5.jpg
9559+1 Datensätze ein
9559+1 Datensätze aus
4894630 Bytes (4,9 MB, 4,7 MiB) kopiert, 0,262784 s, 18,6 MB/s

[Tintom]

Könntest du bitte noch zum Vergleich von einem Nicht-Datenträger lesen und die Blocksize von dd etwas vergrößern?
Etwa so: head -c 1G /dev/zero|dd bs=1M of=/shares/<...>

edit: @heisenberg hat ja weiter oben schon passende Befehle gepostet, die kannst du natürlich auch nehmen.

[nyami]

Here we are:

Code: Alles auswählen

time dd if=/dev/zero bs=1G count=1 of=/shares/nextcloud-data/test/test.bin
1+0 Datensätze ein
1+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 2,29961 s, 467 MB/s

real    0m2,333s
user    0m0,000s
sys     0m1,858s

[heisenberg]

Here we are:

Code: Alles auswählen

time dd if=/dev/zero bs=1G count=1 of=/shares/nextcloud-data/test/test.bin
1+0 Datensätze ein
1+0 Datensätze aus
1073741824 Bytes (1,1 GB, 1,0 GiB) kopiert, 2,29961 s, 467 MB/s

real    0m2,333s
user    0m0,000s
sys     0m1,858s

Hmm. Das sieht mir gecached aus, also nicht wirklich die Schreibgeschwindigkeit des Gerätes.

Ich würde vorschlagen, da mal ein paar mehr Durchgänge durchzuführen. Z. B. 100:

Code: Alles auswählen

for((x=1;x<=100;x++));do 
   dd if=/dev/zero of=/shares/nextcloud-data/test/test.bin \
      bs=100M count=1 2>&1 | grep kopiert
done

Wenn die Schreibgeschwindigkeit sich auf einen niedrigeren Wert eingependelt hat, kannst Du die Schleife abbrechen.

Bei mir bei meinem Desktop sieht das so aus:

Code: Alles auswählen

# Die erste Ausführung mit 1GB Datei war bei 1,5 GB/Sekunde

$ for((x=1;x<=100;x++));do dd if=/dev/zero bs=100M count=1 of=test.bin 2>&1 |grep kopiert;done
104857600 Bytes (105 MB, 100 MiB) kopiert, 1,08518 s, 96,6 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,927968 s, 113 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,880829 s, 119 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 1,06506 s, 98,5 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,900233 s, 116 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 1,37485 s, 76,3 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,924947 s, 113 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,867707 s, 121 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,823654 s, 127 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 1,21706 s, 86,2 MB/s
104857600 Bytes (105 MB, 100 MiB) kopiert, 0,915343 s, 115 MB/s
...

Mein Desktop-PC hat 16 GB RAM. Die Größe des Caches ist afaik per Default in Abhängigkeit von der RAM-Grösse gesetzt.

[heisenberg]

Ansonsten habe ich schon mögliche Schlußfolgerungen im Kopf. Damit warte ich aber noch, bis wirklich verlässliche Zahlen(siehe voriger Beitrag) da sind.

Mittels dstat kannst Du Dir ansonsten die aktuelle/tatsächliche Festplattenaktivität fortlaufend anzeigen lassen:

Code: Alles auswählen

dstat -d -D md127

Beispiel(Ein billiger USB-Stick von mir, auf den ich gerade ein ISO-Image mit dd kopiere):

Code: Alles auswählen

dstat  --disk -D sdb
--dsk/sdb--
 read  writ
 936B  338k
   0  1500k
   0  1896k
   0  1856k
   0  1768k
   0   248k
   0  1880k
   0  1960k
   0  2012k
   0   120k
   0  1996k
   0  1512k
   0  1004k
   0  1616k
   0  2028k
   0  3984k
   0  2168k
   0  2248k
   0  1748k
   0  2356k