[SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

LinuxLover471 · 2025-03-09 17:01:36

Hi, I hope that you are doing well.

I use ventoy to manage my ISO's and play around with different distros, therefore I need to do USB transfers. I saw that when doing one such transfer on my usb2.0 port, which has a theoretical speed of 60MB/s(not achievable,btw.). The transfer immediately cranks up to 500MB or so depending on the size of the ISO file that I have. This also used to be an issue in every other linux distro I have used, mint, debian, endeavour.

Even after using the cp command to transfer the iso file, it still does the speed bump thingy and when I eject the USB drive and try to boot into the ISO file, it always has problems, but if I do the same on windows 10, it does it slowly but consistently, at approx same speed and no speed bump like this at the start.

I think some form of option in cp would fix this? Also using DD command to overwrite/create installation drives always succeeds so this is an issue with copying and pasting(even with cut).

inxi -Fxxxz

System:
  Kernel: 6.13.5-arch1-1 arch: x86_64 bits: 64 compiler: gcc v: 14.2.1
    clocksource: tsc
  Desktop: KDE Plasma v: 6.3.2 tk: Qt v: N/A wm: kwin_x11 vt: 2 dm: SDDM
    Distro: Arch Linux
Machine:
  Type: Desktop Mobo: Gigabyte model: G31M-ES2L serial: <superuser required>
    uuid: <superuser required> BIOS: Award v: FI date: 08/09/2010
CPU:
  Info: quad core model: Intel Core2 Quad Q9550 bits: 64 type: MCP
    smt: <unsupported> arch: Penryn rev: A cache: L1: 256 KiB L2: 12 MiB
  Speed (MHz): avg: 2116 min/max: 2000/2834 cores: 1: 2116 2: 2116 3: 2116
    4: 2116 bogomips: 22668
  Flags: ht lm nx pae sse sse2 sse3 sse4_1 ssse3
Graphics:
  Device-1: NVIDIA GK107 [GeForce GT 740] driver: nvidia v: 470.256.02
    arch: Kepler-2 pcie: speed: 2.5 GT/s lanes: 16 ports: active: none
    off: HDMI-A-1 empty: DVI-I-1,VGA-1 bus-ID: 01:00.0 chip-ID: 10de:0fc8
    class-ID: 0300
  Display: x11 server: X.org v: 1.21.1.16 with: Xwayland v: 24.1.6
    compositor: kwin_x11 driver: X: loaded: nvidia unloaded: modesetting
    alternate: fbdev,nouveau,nv,vesa gpu: nvidia,nvidia-nvswitch
    display-ID: :0 note: <missing: xdpyinfo/xrandr>
  Monitor-1: HDMI-A-1 model: LG (GoldStar) FHD serial: <filter>
    res: 1920x1080 dpi: 102 size: 480x260mm (18.9x10.24") diag: 546mm (21.5")
    modes: max: 1920x1080 min: 640x480
  API: OpenGL Message: Unable to show GL data. glxinfo is missing.
  Info: Tools: de: kscreen-doctor gpu: nvidia-settings,nvidia-smi x11: xprop
Audio:
  Device-1: Intel NM10/ICH7 Family High Definition Audio
    vendor: Gigabyte GA-D525TUD driver: snd_hda_intel v: kernel bus-ID: 00:1b.0
    chip-ID: 8086:27d8 class-ID: 0403
  Device-2: NVIDIA GK107 HDMI Audio driver: snd_hda_intel v: kernel pcie:
    speed: 2.5 GT/s lanes: 16 bus-ID: 01:00.1 chip-ID: 10de:0e1b class-ID: 0403
  API: ALSA v: k6.13.5-arch1-1 status: kernel-api
  Server-1: JACK v: 1.9.22 status: off
  Server-2: PipeWire v: 1.2.7 status: active with: 1: pipewire-pulse
    status: active 2: wireplumber status: active 3: pipewire-alsa type: plugin
Network:
  Device-1: Qualcomm Atheros AR8131 Gigabit Ethernet
    vendor: Gigabyte GA-G31M-ES2L driver: atl1c v: kernel pcie: speed: 2.5 GT/s
    lanes: 1 port: bf00 bus-ID: 03:00.0 chip-ID: 1969:1063 class-ID: 0200
  IF: enp3s0 state: down mac: <filter>
  Device-2: Ralink RT5370 Wireless Adapter driver: rt2800usb type: USB
    rev: 2.0 speed: 480 Mb/s lanes: 1 bus-ID: 2-6:4 chip-ID: 148f:5370
    class-ID: 0000 serial: <filter>
  IF: wlan0 state: up mac: <filter>
Drives:
  Local Storage: total: 1.39 TiB used: 57.29 GiB (4.0%)
  ID-1: /dev/sda vendor: A-Data model: SU800 size: 476.94 GiB
    speed: <unknown> tech: SSD serial: <filter> fw-rev: 8B scheme: MBR
  ID-2: /dev/sdb vendor: Toshiba model: DT01ACA100 size: 931.51 GiB
    speed: <unknown> tech: HDD rpm: 7200 serial: <filter> fw-rev: A7C0
    scheme: MBR
  ID-3: /dev/sdc vendor: SanDisk model: Cruzer Blade size: 14.91 GiB
    type: USB rev: 2.0 spd: 480 Mb/s lanes: 1 speed: <unknown> tech: N/A
    serial: <filter> fw-rev: 1.00 scheme: MBR
Partition:
  ID-1: / size: 173.1 GiB used: 15.63 GiB (9.0%) fs: ext4 dev: /dev/sda1
  ID-2: /home size: 14.66 GiB used: 2.77 GiB (18.9%) fs: ext4 dev: /dev/sda6
Swap:
  ID-1: swap-1 type: zram size: 1.91 GiB used: 0 KiB (0.0%) priority: 100
    dev: /dev/zram0
  ID-2: swap-2 type: partition size: 8 GiB used: 0 KiB (0.0%) priority: -2
    dev: /dev/sda3
Sensors:
  System Temperatures: cpu: 55.0 C mobo: N/A gpu: nvidia temp: 48 C
  Fan Speeds (rpm): N/A gpu: nvidia fan: 30%
Info:
  Memory: total: 4 GiB available: 3.82 GiB used: 1.85 GiB (48.3%)
  Processes: 184 Power: uptime: 16m states: freeze,mem,disk suspend: deep
    wakeups: 0 hibernate: platform Init: systemd v: 257 default: graphical
  Packages: pm: pacman pkgs: 781 Compilers: clang: 19.1.7 gcc: 14.2.1
    Shell: Bash v: 5.2.37 running-in: konsole inxi: 3.3.37

Also the speed is miserably slow after the speed bump, something like 1.2MB/s whereas it would go at 5.8/6.1MB/s consisently. And after this it rises to 5MB/s.
Thanks,
LL

Last edited by LinuxLover471 (2025-08-05 03:35:59)

kermit63 · 2025-03-09 17:43:18

The speed is fast at first since the file is being written to a buffer in the computer's ram. Once this gets filled up, buffer memory can only be freed up as fast as it can write to the USB, which is very slow.

You should make it a habit of running the 'sync' command, then subsequently unmount the USB before taking it out physically. This is to make sure the last bits of data are written to the USB.

loqs · 2025-03-09 19:02:43

kermit63 wrote:

You should make it a habit of running the 'sync' command, then subsequently unmount the USB before taking it out physically. This is to make sure the last bits of data are written to the USB.

umount has never completed for me until data has been flushed to the device. Has it for you?

kermit63 · 2025-03-09 19:11:09

After sync, unmount completes almost instantaneously for me. sync takes a long time though.

I've never attempted an unmount without doing a sync.

Last edited by kermit63 (2025-03-09 19:13:33)

seth · 2025-03-09 21:16:11

Expect umount to implicitly sync the FS - the danger is to just yank the disk w/o a completed sync (ie. because IO hasn't completed, you've not byte-garbage on the destination drive)

but if I do the same on windows 10, it does

… measure the destination size and project the duration.
This is theoretically possible, I'm not aware of any tool doing this and it will slow down the overall process (though probably not that much for a USB key where writing is much slower than reading)

You can play w/ the cache, https://lonesysadmin.net/2013/12/22/bet … rty_ratio/
Do not resort to silly stuff like sync mounts, that will age your usb key much faster.

Xephon · 2025-03-09 21:26:34

You want to see an actual USB transfer progress? It's possible by limiting writing cache size via udev rules.

Clone and install https://github.com/biglinux/usb-dirty-pages-udev
It basically adds a udev rule and a shell script that is executed by that rule.

In order to trigger a rule, USB devices must be automounted. Setup automount on attach in System Settings->Disks & Cameras->Device Automount

After setup is done, remove USB device, attach it again and copy some files. Transfer speed should reflect a real writing speed of your USB stick.

LinuxLover471 · 2025-03-12 07:09:57

Sorry for being super late, I was busy in fixing my partition layout as I used to use 170GB for the root partition in arch linux, overkill, resized it to 70GB.

Also, the issue is fixed, by using sync before unmounting or not using sync but unmounting and after that ejecting with sudo eject (drivepartition), this problem gets fixed and the iso's get transferred safely and work as expected.

Thanks,
LL

Arch Linux

#1 2025-03-09 17:01:36

[SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#2 2025-03-09 17:43:18

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#3 2025-03-09 19:02:43

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#4 2025-03-09 19:11:09

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#5 2025-03-09 21:16:11

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#6 2025-03-09 21:26:34

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

#7 2025-03-12 07:09:57

Re: [SOLVED] Unreliable but impossibly fast USB transfers on arch linux.

Board footer