Copy to USB is very slow

Bug #1728053 reported by csola48 on 2017-10-27
This bug affects 3 people
Affects Status Importance Assigned to Milestone
nautilus (Ubuntu)

Bug Description

Ubuntu 16.04.3 LTS from 32 bit machines to a USB stick or winchester, the speed is approx. starting at 25MB/s, it slows down to 100kB/s. At the end of the copying, you will stand for a long time. A ca. Copy the 1.5GB file to approx. it lasts for 20 minutes: unusable ...
Ports and Devices: USB2 and USB3.

4.10.0-37-generic #41~16.04.1-Ubuntu SMP Fri Oct 6 22:42:22 UTC 2017

Changed in nautilus (Ubuntu):
importance: Undecided → Low
csola48 (mail-csordaslaszlo) wrote :

dirty_background_bytes: 0
dirty_background_ratio: 10
dirty_bytes: 0
dirty_ratio: 20
dirtytime_expire_seconds: 43200
dirty_expire_centisecs: 3000
dirty_writeback_centisecs: 500

Sebastien Bacher (seb128) wrote :

thank you for your bug report, is it better if you copy from another filemanager or from a commandline?

csola48 (mail-csordaslaszlo) wrote :

Typically, e.g. Select a file (desktop) > drag and drop copying / moving > target USB flash drive / external USB hard disk
I do not typically use a command line

csola48 (mail-csordaslaszlo) wrote :

Note: Previously there were no such anomalies at 16.04... After many updates and patches to the LTS version come in, I'm not sure what to do with the phenomenon.
But it is a fact that several weeks exist

csola48 (mail-csordaslaszlo) wrote :

The previously "dirty" values are original. Are these values normal?

csola48 (mail-csordaslaszlo) wrote :

Some more info:
$ cat /proc/vmstat | egrep "dirty|writeback"
nr_dirty 0
nr_writeback 0
nr_writeback_temp 0
nr_dirty_threshold 0
nr_dirty_background_threshold 0

Each "0" ... Is that OK? (Original values!)

csola48 (mail-csordaslaszlo) wrote :

1) Values from the sysctl file:
vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.compact_unevictable_allowed = 1
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 20
vm.dirty_writeback_centisecs = 500
vm.dirtytime_expire_seconds = 43200
vm.drop_caches = 0
vm.extfrag_threshold = 500
vm.highmem_is_dirtyable = 0
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256 32 32
vm.max_map_count = 65530
vm.min_free_kbytes = 34096
vm.mmap_min_addr = 65536
sysctl: permission denied on key 'vm.mmap_rnd_bits'
vm.nr_hugepages = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50 = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
sysctl: permission denied on key 'vm.stat_refresh'
vm.swappiness = 60
vm.user_reserve_kbytes = 131072
vm.vdso_enabled = 1
vm.vfs_cache_pressure = 100
vm.watermark_scale_factor = 10

2) My machine has 16GB of memory
3) Copy from the desktop to a 16GB USB flash drive

csola48 (mail-csordaslaszlo) wrote :

Comment # 4 on bug 789647 from Ondrej Holy from

"Thanks for your reply. If "cp" is also so slow, then the bug is not in GNOME
layer. It is probably something wrong in kernel..."

Mitch Oldroyd (moldy01) wrote :

this is apparently also a problem in Bionic-Beaver. I started a file copy 7,633 files to a new USB stick (SSD to USB 3.1). The copy started out like I expected, at a displayed rate of about 345MB/s. By the time, it reached roughly 1/2 the copy began to slow and before long, it was down to about 34MB/s.

This is after recovering from a very similar issue Friday (last). Where in, it slowed even further, down to 1.2MB/s. I did the research over the weekend, and found reports, very similar to this one, attributing the issues to the Nautilus FS. I also found that Ubuntu 18.04 chose to not update Nautilus, but rather stayed with a previous version.

lsb_release -a gives
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04 LTS
Release: 18.04
Codename: bionic

Machine info:
Memory 3.13GeForce GTX 1070 with Max-Q Design/PCIe/SSE2 GiB
Processor: Intel® Core™ i7-7700HQ CPU @ 2.80GHz × 8
Graphics: GeForce GTX 1070 with Max-Q Design/PCIe/SSE2
GNOME: 3.28.1
OS type: 64-bit
Disk : 97.9 GB

(500 GB SSD partitioned into 100 for OS, 400 for local storage)

cat /proc/vmstat | egrep "dirty|writeback" yields: (about 2 min after slow transfer finished)

nr_dirty 48
nr_writeback 0
nr_writeback_temp 0
nr_dirty_threshold 1502867
nr_dirty_background_threshold 750516

On Friday, I did try to use the command line "cp" on a smaller subset of the file set, with no visual, I cannot say xfer rate, however, it took quite a while (over 5 minutes) to transfer approximately 1500 2MB files.

Not sure if there is anything more that I can provide. Oh,a colleague with whom I was sharing these files, was able to upload them (after my laborious download) onto his ubuntu 18.04 in like 20 seconds or so.

Sebastien Bacher (seb128) wrote :

is anyone still having the issue in bionic and test if using cp/gio copy command give a different behaviour?

Changed in nautilus (Ubuntu):
status: New → Incomplete
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.