dd langsamer als dateisystem

[nudgegoonies]

Ich wollte den Durchsatz einer externen Platte via USB 3 messen, die vor allem beim Schreiben langsam ist (anders Thema). Um das Dateisystem als Ursache auszuschließen habe ich ungemounted gemessen wie schnell sie im Lesen ist. Ein einfaches dd mit status=progress des blockdevices nach /dev/null bringt lediglich 3MB/s. Ich habe 512 Byte, 4KB und 4MB als Blockgrößen ausprobiert. Fast keine Veränderung.

Code: Alles auswählen

dd if=/dev/sdb of=/dev/null bs=WERT status=progress

Die Platte ist btrfs formatiert und ich habe ein scrub laufen lassen. Das liest von der Platte mit 106 MB/s. Das ist 35 mal schneller als dd. Hat jemand eine Idee, was dd hier so bremst?

Vielleicht hängt das ja auch mit der langsamen Schreibgeschwindigkeit zusammen auf Dateisystemebene zusammen.

Die gpt btrfs Partition ist mit gparted angelegt und formatiert und an MB ausgerichtet und SMART alle Werte sind ohne Tadel. Das einzige was mich wundert ist, dass die Platte das trim Kommando unterstützt. Dabei ist es ja eine normale Platte und keine SSD.

Kernel Logs des ansteckens:

Code: Alles auswählen

[Mi Jul 26 08:22:17 2023] usb 2-4: new SuperSpeed Gen 1 USB device number 4 using xhci_hcd
[Mi Jul 26 08:22:17 2023] usb 2-4: New USB device found, idVendor=1058, idProduct=2621, bcdDevice=10.26
[Mi Jul 26 08:22:17 2023] usb 2-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Mi Jul 26 08:22:17 2023] usb 2-4: Product: Elements 2621
[Mi Jul 26 08:22:17 2023] usb 2-4: Manufacturer: Western Digital
[Mi Jul 26 08:22:17 2023] usb 2-4: SerialNumber: 57584D314141394B36555850
[Mi Jul 26 08:22:17 2023] usb-storage 2-4:1.0: USB Mass Storage device detected
[Mi Jul 26 08:22:17 2023] scsi host4: usb-storage 2-4:1.0
[Mi Jul 26 08:22:18 2023] scsi 4:0:0:0: Direct-Access     WD       Elements 2621    1026 PQ: 0 ANSI: 6
[Mi Jul 26 08:22:18 2023] sd 4:0:0:0: Attached scsi generic sg1 type 0
[Mi Jul 26 08:22:18 2023] sd 4:0:0:0: [sdb] Spinning up disk...
[Mi Jul 26 08:22:19 2023] ....ready
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] 3906963456 512-byte logical blocks: (2.00 TB/1.82 TiB)
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] Write Protect is off
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] Mode Sense: 47 00 10 08
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] No Caching mode page found
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] Assuming drive cache: write through
[Mi Jul 26 08:22:22 2023]  sdb: sdb1
[Mi Jul 26 08:22:22 2023] sd 4:0:0:0: [sdb] Attached SCSI disk
[Mi Jul 26 08:22:23 2023] BTRFS: device label andreasbak devid 1 transid 1795 /dev/sdb1 scanned by systemd-udevd (98165)
[Mi Jul 26 08:23:04 2023] BTRFS info (device sdb1): using crc32c (crc32c-intel) checksum algorithm
[Mi Jul 26 08:23:04 2023] BTRFS info (device sdb1): flagging fs with big metadata feature
[Mi Jul 26 08:23:04 2023] BTRFS info (device sdb1): disk space caching is enabled
[Mi Jul 26 08:23:04 2023] BTRFS info (device sdb1): has skinny extents

[Tintom]

Interessant. Ist es mit anderen Tools ähnlich?
z.B.

• time head -c 1G /dev/sdb > /dev/null
• pv /dev/sdb > /dev/null

[wanne]

* Dateisysteme cache. Das kann von Vorteil sein. halte ich aber bei einem scrub für unwahrscheinlich.
* dd unterbricht seinen Lesevorgang alle bs=WERT. Gerade bei platten kann das dazu führen dass die Platte langsam neu seeken muss. Bei 4MiB-Blöcken sollte das aber keine relevante Rolle mehr spielen und vor allem solltest du den Unterschied zu 4kiB deutlich sehen.