Das Schreiben auf meinen USB-3-Stick (SanDisk Extreme SDCZ80-064G-FFP) ist unter Linux sehr langsam: 1 GB dauert länger als 200 Sekunden. Unter Windows (Dual-Boot auf demselben Computer) kann dieselbe 1-GB-Datei in etwa 8 Sekunden kopiert werden. Der Stick ist in FAT formatiert (er war vorformatiert und ich habe es nicht geändert) und ich möchte es so belassen, da ich ihn auch unter Windows verwende.
Wie kann ich das Problem beheben? Welche Schritte kann ich ausführen, um die Ursache zu diagnostizieren?
Ich verwende Manjaro/Arch mit Kernelversion 4.5.4-1.
Bearbeiten:
Zunächst einmal: Als ich versuchte, es mit zu mounten, wurde mir klar, dass das Laufwerk im FAT-Format formatiert ist (nicht im NTFS-Format, wie ich ursprünglich in der Frage angegeben hatte) -o big_writes. Entschuldigen Sie den Fehler!
Ich füge die Ausgaben der in den Kommentaren genannten Befehle hinzu. Ich sehe bei keinem davon ein Problem.
Ausgabe, journalctl -fwenn ich das Laufwerk anschließe, mounte und einige Daten schreibe:
Mai 23 20:32:37 manjaro kernel: usb 2-6: USB disconnect, device number 7
Mai 23 20:32:39 manjaro dbus[608]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
Mai 23 20:32:39 manjaro dbus[608]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
Mai 23 20:32:41 manjaro kernel: usb 2-6: new SuperSpeed USB device number 8 using xhci_hcd
Mai 23 20:32:41 manjaro kernel: usb-storage 2-6:1.0: USB Mass Storage device detected
Mai 23 20:32:41 manjaro kernel: scsi host12: usb-storage 2-6:1.0
Mai 23 20:32:41 manjaro mtp-probe[3627]: checking bus 2, device 8: "/sys/devices/pci0000:00/0000:00:14.0/usb2/2-6"
Mai 23 20:32:41 manjaro mtp-probe[3627]: bus: 2, device: 8 was not an MTP device
Mai 23 20:32:42 manjaro kernel: scsi 12:0:0:0: Direct-Access SanDisk Extreme 0001 PQ: 0 ANSI: 6
Mai 23 20:32:42 manjaro kernel: sd 12:0:0:0: [sdc] 122544516 512-byte logical blocks: (62.7 GB/58.4 GiB)
Mai 23 20:32:42 manjaro kernel: sd 12:0:0:0: [sdc] Write Protect is off
Mai 23 20:32:42 manjaro kernel: sd 12:0:0:0: [sdc] Mode Sense: 53 00 00 08
Mai 23 20:32:42 manjaro kernel: sd 12:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
Mai 23 20:32:42 manjaro kernel: sdc: sdc1
Mai 23 20:32:42 manjaro kernel: sd 12:0:0:0: [sdc] Attached SCSI removable disk
Mai 23 20:32:43 manjaro dbus[608]: [system] Activating via systemd: service name='org.freedesktop.Avahi' unit='dbus-org.freedesktop.Avahi.service'
Mai 23 20:32:43 manjaro dbus[608]: [system] Activation via systemd failed for unit 'dbus-org.freedesktop.Avahi.service': Unit dbus-org.freedesktop.Avahi.service not found.
Mai 23 20:32:52 manjaro sudo[3667]: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/mount /dev/sdc1 /mnt/
Mai 23 20:32:52 manjaro sudo[3667]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mai 23 20:32:52 manjaro sudo[3667]: pam_unix(sudo:session): session closed for user root
Mai 23 20:33:11 manjaro sudo[3676]: user : TTY=pts/1 ; PWD=/home/user ; USER=root ; COMMAND=/usr/bin/dd bs=1M count=1024 if=/dev/zero of=/mnt/test conv=fdatasync status=progress
Mai 23 20:33:11 manjaro sudo[3676]: pam_unix(sudo:session): session opened for user root by (uid=0)
Mai 23 20:35:01 manjaro anacron[2235]: Job `cron.daily' started
Mai 23 20:35:03 manjaro anacron[2235]: Job `cron.daily' terminated
Mai 23 20:35:45 manjaro sudo[3676]: pam_unix(sudo:session): session closed for user root
Ausgabe von dmesg:
[ 2507.302345] usb 2-6: new SuperSpeed USB device number 8 using xhci_hcd
[ 2507.317395] usb-storage 2-6:1.0: USB Mass Storage device detected
[ 2507.317758] scsi host12: usb-storage 2-6:1.0
[ 2508.319922] scsi 12:0:0:0: Direct-Access SanDisk Extreme 0001 PQ: 0 ANSI: 6
[ 2508.333123] sd 12:0:0:0: [sdc] 122544516 512-byte logical blocks: (62.7 GB/58.4 GiB)
[ 2508.333353] sd 12:0:0:0: [sdc] Write Protect is off
[ 2508.333362] sd 12:0:0:0: [sdc] Mode Sense: 53 00 00 08
[ 2508.333634] sd 12:0:0:0: [sdc] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA
[ 2508.346488] sdc: sdc1
[ 2508.347918] sd 12:0:0:0: [sdc] Attached SCSI removable disk
Zum Mounten und Schreiben verwendete Befehle:
$ sudo mount /dev/sdc1 /mnt/
$ sudo dd bs=1M count=1024 if=/dev/zero of=/mnt/test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1,1 GB, 1,0 GiB) copied, 154,158 s, 7,0 MB/s
Ausgabe von lsusb -t:
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 5000M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/2p, 480M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/10p, 5000M
|__ Port 6: Dev 8, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/16p, 480M
|__ Port 9: Dev 2, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 10: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
|__ Port 10: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M
Bearbeitung 2:Ich habe zwei andere Kernel ausprobiert: 4.4.11 und 4.6.0. Das Schreiben ist mit beiden immer noch langsam. Außerdem scheint das Problem mit dem Laufwerk zusammenzuhängen, da ich mit einer externen USB 3-Festplatte höhere Übertragungsgeschwindigkeiten (90 MB/s) erreiche.
Bearbeitung 3:Ich habe einige Benchmarks auf einem Ubuntu 16.04 Live-System durchgeführt. Die Ergebnisse sind viel besser (aber immer noch nicht sehr gut):
ubuntu@ubuntu:/media/ubuntu/274D-D62C$ dd bs=1M count=1024 if=/dev/zero of=./test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 12.2623 s, 87.6 MB/s
ubuntu@ubuntu:/media/ubuntu/274D-D62C$ dd bs=1M count=1024 if=/dev/zero of=./test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 64.5742 s, 16.6 MB/s
ubuntu@ubuntu:/media/ubuntu/274D-D62C$ dd bs=1M count=1024 if=/dev/zero of=./test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 83.6521 s, 12.8 MB/s
ubuntu@ubuntu:/media/ubuntu/274D-D62C$ dd bs=1M count=1024 if=/dev/zero of=./test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 21.842 s, 49.2 MB/s
ubuntu@ubuntu:/media/ubuntu/274D-D62C$ dd bs=1M count=1024 if=/dev/zero of=./test conv=fdatasync status=progress
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB, 1.0 GiB) copied, 16.3149 s, 65.8 MB/s
Bearbeitung 4:Ich habe es gerade noch einmal mit einem aktuellen Arch/Manjaro-Kernel (4.11.1) versucht und das Ergebnis ist etwas besser: Ich erhalte Übertragungsgeschwindigkeiten von etwa 10 MB/s (also ~100 s für 1 GB). Das ist allerdings immer noch viel langsamer als Windows.
Bearbeitung 5:Ich habe endlich die Zeit gefunden, auf dieses Problem zurückzukommen. Mit dem aktuellen Manjaro-Kernel Linux janmanjaro 5.4.74-1-MANJARO #1 SMP PREEMPT Sun Nov 1 13:43:13 UTC 2020 x86_64 GNU/Linuxerreiche ich 15 - 30 MB/s (normalerweise näher an 15 MB/s). Mounten mit sudo mount -o async,flush /dev/sdc1 /mnt/(wie in vorgeschlagenExtrem langsame Geschwindigkeit beim Schreiben auf ein USB-FAT32-Laufwerk unter Linux) verbessert die Geschwindigkeit um etwa 5 MB/s. Das ist immer noch lächerlich langsamer als Windows und auch viel langsamer als Ubuntu.
Ich bin auch sudo fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reportinwie von @Mikko Rantalainen vorgeschlagen gelaufen. Die Ergebnisse sind:
Run status group 0 (all jobs):
READ: bw=3444KiB/s (3527kB/s), 3444KiB/s-3444KiB/s (3527kB/s-3527kB/s), io=202MiB (212MB), run=60001-60001msec
WRITE: bw=3432KiB/s (3514kB/s), 3432KiB/s-3432KiB/s (3514kB/s-3514kB/s), io=201MiB (211MB), run=60001-60001msec
Ich habe dies noch nicht auf Ubuntu ausgeführt.
Antwort1
Brauchen Sie wirklich FAT? Meiner Erfahrung nach greift die Linux-Implementierung des FAT-Treibers in einer Reihenfolge auf das Gerät zu, die bei manchen Geräten zu einer wirklich schlechten Leistung führt. Ich habe bei manchen Flash-Geräten eine 10-fache Leistungssteigerung festgestellt, wenn sie stattdessen als ext4 formatiert wurden.
In Anbetracht dessen, dass der Link, den Sie in den Kommentaren angegeben haben (http://www.beginninglinux.com/home/machine-related/sandisk-extreme-64-usb-3-speed-test-benchmark-review) Lese- und Schreibgeschwindigkeiten ohne Partitionen getestet hat, kann es sein, dass Ihr Flash-Gerät eine schlechte Leistung zeigt, wenn es über einen Linux-FAT-Treiber aufgerufen wird. Wenn das zutrifft, sollte es auch allgemein eine schlechte Leistung bei zufälligen E/A-Vorgängen aufweisen.
Sie können die Leistung des Geräts mit testen fio. Wechseln Sie in ein Verzeichnis innerhalb des Geräts, das Sie testen möchten, und führen Sie den folgenden Befehl aus, um die Leistung mit gemischter zufälliger 4K-Lese-/Schreibleistung zu testen:
fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=4k --ioengine=libaio --iodepth=1 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Dadurch wird eine 500 MB große Testdatei erstellt test.imgund dann mit dem Lesen und Schreiben in zufälligen 4 KB-Blöcken mit einer Warteschlangentiefe von 1 begonnen. Erhöhen Sie den Wert, sizefalls Ihr Gerät über einen großen internen Cache verfügt. Dieser Test hat eine maximale Laufzeit von 60 Sekunden. Betrachten Sie dies als das Worst-Case-Szenario mit Ihrem Gerät. Ein ziemlich schnelles Flash-Gerät (Intel SSD 910) erzielt hier folgende Ergebnisse:
...
read : io=1041.4MB, bw=17773KB/s, iops=4443, runt= 60001msec
...
write: io=1038.5MB, bw=17723KB/s, iops=4430, runt= 60001msec
...
Um den besten Fall zu testen, können Sie die Blockgröße erhöhen und zwei parallele Prozesse mit iodepth=32 ausführen:
fio --name TEST --eta-newline=5s --filename=test.img --rw=randrw --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=2 --runtime=60 --group_reporting
Ein relativ schnelles Flash-Gerät (Intel SSD 910) erzielt hier folgende Ergebnisse:
...
read : io=10892MB, bw=457088KB/s, iops=892, runt= 24401msec
...
write: io=9588.0MB, bw=402365KB/s, iops=785, runt= 24401msec
...
Wenn Sie wirklich hohe Punktzahlen erzielen möchten, sollten Sie natürlich sequentielles Lesen mit hoher iodepth durchführen. Dies sollte in der Nähe der Zahlen liegen, die Sie in den technischen Datenblättern der Geräte sehen (das heißt, nie im wirklichen Leben):
fio --name TEST --eta-newline=5s --filename=test.img --rw=read --size=500m --io_size=10g --blocksize=512k --ioengine=libaio --iodepth=32 --direct=1 --numjobs=1 --runtime=60 --group_reporting
Ein relativ schnelles Flash-Gerät (Intel SSD 910) erzielt hier folgende Ergebnisse:
...
read : io=10240MB, bw=1468.8MB/s, iops=2937, runt= 6972msec
...
Beachten Sie, dass dies nicht mit den Angaben auf dem Datenblatt übereinstimmt (ca. 2 GB/s), da ich den E/A-Scheduler mit der geringstmöglichen Latenz konfiguriert habe ( deadlineE/A-Scheduler mit 1 > ../queue/iosched/fifo_batchund 50 > ../queue/iosched/read_expire).
Beachten Sie den enormen Unterschied zwischen dem Worst-Case-Szenario (ca. 17 MB/s) und dem Best-Case-Szenario (ca. 1470 MB/s).
Antwort2
Da es keine bessere Antwort gibt, wollte ich nur anmerken, dass Ihre Werte für einen Flash-Speicher im Allgemeinen sehr gut sind und für Ihren spezifischen Flash-Speicher durchaus im erwarteten Bereich liegen.
Marketingangaben wie 190 MB/s Schreibgeschwindigkeit sind im Allgemeinen nicht haltbar (sie gelten höchstens ein paar Sekunden, bis der interne Puffer voll ist, und spiegeln nicht die tatsächliche Flash-Leistung wider) und gelten nur für sequentielle Schreibvorgänge. Sobald ein Dateisystem beteiligt ist, nimmt die Geschwindigkeit erheblich ab. Schreibgeschwindigkeiten mit wahlfreiem Zugriff liegen selbst bei hochwertigen schnellen USB-Laufwerken oft unter 1 MB/s, sodass schon wenige zufällige Schreibvorgänge (wie sie Dateisysteme normalerweise erfordern) die Schreibleistung zerstören können.
Sie können versuchen, ein Flash-freundlicheres Dateisystem wie f2fs zu verwenden (ein Kernel 4.4 oder neuer wird empfohlen), das zufällige Schreibvorgänge gut reduziert, um zu sehen, ob das hilft.
Antwort3
Ich gebe Ihnen hier einen Hoffnungsschimmer. Ich schaue mir UHS-II-SD-Karten und USB-Lesegeräte an und stelle auf der Benchmarking-Registerkarte des Ubuntu-Applets „Disks“ Folgendes fest:
- Ubuntu 14.04 – Kernel 4.4 – Lesen ~140 MB/s, Schreiben ~50 MB/s
- Ubuntu 17.04 – Kernel 4.10 – Lesen ~270 MB/s, Schreiben ~200 MB/s
Diese verwenden den herkömmlichen „USB-Massenspeichertreiber“. Zwischen diesen beiden Punkten hat sich im Kernel etwas geändert, was den Massenspeichertreiber beschleunigt.
Es gelten die üblichen Kommentare zum erneuten Benchmarking. Unsere interne Anwendung ist jedoch etwa 10 % schneller als die Benchmarkzeiten und stellt daher viele Anwendungsfälle recht gut dar.
Externe USB-Festplatten verwenden möglicherweise einen anderen Treiber als den allgemeinen Massenspeichertreiber. Daher ist ein direkter Vergleich nicht immer möglich.
Antwort4
Ich weiß, das ist etwas veraltet, aber
Ich war extrem frustriert, als ich einen Ubuntu-Server 20.04 über USB 3 auf einer 12T Seagate-Erweiterungsfestplatte sichern musste. Die Übertragungsgeschwindigkeiten wurden meistens in Kilobyte angegeben. Und alle 20 Sekunden oder so blieb alles für 10 bis 15 Sekunden stehen. Ich vermute, es handelte sich um eine Art Cache-Schreibvorgang.
Lösungen? Ich habe in den letzten Monaten mehrere aus dem Internet ausprobiert, darunter das Ändern des NTFS-Formats in ext4, das Herumspielen mit den Cache-Einstellungen, das Ändern der Kabel usw. Wenn Sie betroffen sind, haben Sie das sicher schon durchgemacht. Nichts hat geholfen.
Gestern habe ich die Festplatte aus dem Gehäuse gerissen. Sie war mit einer Barracuda gekennzeichnet. Ich habe die Festplatte in eine USB-3-Dockingstation an meinem Desktop-PC gesteckt und ein Rsync-Backup über das LAN gestartet. Bingo – tolle kontinuierliche Übertragungsgeschwindigkeiten
Ich bin zu dem Schluss gekommen, dass das Problem am Controller im Seagate-Erweiterungsgehäuse liegt und nicht an Linux. Dass die Erweiterungsfestplatte unter Windows 10 gut funktionierte, lässt darauf schließen, dass sie möglicherweise auch für dieses System optimiert ist.
Ich habe die Dockingstation nun an einen USB 3-Port des Ubuntu-Servers angeschlossen, wo sie derzeit mit ~50 MB/s sichert.
Ich kann damit leben.