Ubuntu slows down and hangs while copying file from/to USB

Bug #1208993 reported by Merlijn Sebrechts on 2013-08-06
This bug affects 109 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)

Bug Description


While copying many and large files to and from a USB drive, the system becomes incredibly slow and sometimes hangs. I watched the system monitor while it was running slowly but cpu was not above 50% at any time, the same for memory.

I'm using the "WD my passport" HD with a USB3 port of my "ASUS K55VD" laptop.

Description: Ubuntu 13.04
Release: 13.04

  Installed: 1:3.6.3-0ubuntu16
  Candidate: 1:3.6.3-0ubuntu16
  Version table:
 *** 1:3.6.3-0ubuntu16 0
        500 http://ubuntu-archive.mirror.nucleus.be/ raring/main amd64 Packages
        100 /var/lib/dpkg/status

Steps to reproduce:
1) Aquire many large files (like your totally legit moviecollection)
2) Copy files to external HD
3) Open your browser and be sad when your system becomes incredibly slow after a few minutes

This is my first bugreport so if I'm missing something, please tell me.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: nautilus 1:3.6.3-0ubuntu16
ProcVersionSignature: Ubuntu 3.8.0-27.40-generic
Uname: Linux 3.8.0-27-generic x86_64
ApportVersion: 2.9.2-0ubuntu8.1
Architecture: amd64
Date: Tue Aug 6 22:56:34 2013
EcryptfsInUse: Yes
ExecutablePath: /usr/bin/nautilus
 b'org.gnome.nautilus.window-state' b'geometry' b"'656x715+154+151'"
 b'org.gnome.nautilus.window-state' b'maximized' b'true'
InstallationDate: Installed on 2013-05-31 (67 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Release amd64 (20130424)
MarkForUpload: True
SourcePackage: nautilus
UpgradeStatus: No upgrade log present (probably fresh install)

Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in nautilus (Ubuntu):
status: New → Confirmed
Changed in nautilus (Ubuntu):
assignee: nobody → satishsaley (satishsaley)
assignee: satishsaley (satishsaley) → nobody
Matiss Jekabsons (matiss-v) wrote :

I am using Ubuntu 14.04LTS on Dell XPS 13 L321x and i am affected with this bug, too.

Simon P. (simpre) wrote :

I am affected by this problem too, running Ubuntu 14.04 64 bit.

"dirty files" seem to cause this problem on 64 bit systems. I solved it on my system by decreasing the dirty files cache. This article explains it in detail: http://lonesysadmin.net/2013/12/22/better-linux-disk-caching-performance-vm-dirty_ratio/

zzarko (zzarko-gmail) wrote :

As time goes by, my 14.04 64bit instalation performs worse and worse when doing anything with USB discs (flash or HD, doesn't matter).

If I start to copy a big file from/to flash USB, started programs usually work to a degree (if they don't require access to HD), but if I try to start something simple, like a terminal, during this, it will be started AFTER the copying was finished.

Similar thing happens when copying from/to USB HD, only not as severe as with Flash USB discs (the system is somewhat less laggy).

This is something that was frequent in my win xp days and after I switched to Linux in 2005 I tought that something like this is waaay behind me. Now, newer versions of Ubuntu are again showing me the joys of system lockup while working with USB discs.

joseph tom (vamattom) wrote :

@Simon P. (simpre) thank you...
64bit 14.04 is working fine after adding following lines

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

in /etc/sysctl.conf
and running sysctl -p

Benji (sandoval-alvarez) wrote :

Confirmed when I try to copy files to or frome my usb disck.

@Simon P. (simpre) thank you...
Changed my life adding

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

in /etc/sysctl.conf
and running sysctl -p

************** lsb_relase *************
LSB Version: core-2.0-amd64:core-2.0-noarch:core-3.0-amd64:core-3.0-noarch:core-3.1-amd64:core-3.1-noarch:core-3.2-amd64:core-3.2-noarch:core-4.0-amd64:core-4.0-noarch:core-4.1-amd64:core-4.1-noarch:security-4.0-amd64:security-4.0-noarch:security-4.1-amd64:security-4.1-noarch
Distributor ID: Ubuntu
Description: Ubuntu 14.10
Release: 14.10
Codename: uto

zzarko (zzarko-gmail) wrote :

Tried that a while ago, it made working with already open applications and playing music OK (it stopped stuttering while copying), but if I copy something large and want, for example, to start a terminal window, I can click on terminal icon, but the window won't be shown until copying is finished. I mean, how much disk activity is needed for opening terminal window?

I have 3 harddisks in my machine. Let's say that OS is on HD1. The same problem with starting terminal occurs even if I start copying from HD2 to HD3, so I guess it has nothing to do with HD speed and/or caching.

And this is not only Nautilus problem (at least for me). Same thing happens if I copy/unpack from command line, or Double Commander (unpackig large archives does the same thing). Generally, every time some process has a lot of work with hard drive (it doesn't need to be an USB HD, that makes things just more sluggish), my computer is noticeably less usable until HD work is finished. I think that something is wrong with the way I/O operations are scheduled, as some processes can take all the machine's disk I/O resources for themselves, leaving absolutely nothing for others.

Ubfan (ubfan1) wrote :

The default cache setup on Ubuntu 14.04 (no explicit settings in sysctl.conf) seems to use bytes instead of a ratio:
$ cat /proc/vmstat | egrep "dirty|writeback"
nr_dirty 43
nr_writeback 0
nr_writeback_temp 0
nr_dirty_threshold 169462
nr_dirty_background_threshold 84731

This default is for a system with 8G memory, so are probably too small.

The problem caused by this default settings is slow file copies (10 MB/sec) from a SATA hd to a USB3 (SATA disk).

Using a ratio for the default settings instead of a number of bytes might allow better use of memory for machines with memory to spare.

Hello, today I experienced this problem for the first time. The only change on my laptop was the addition of 4GB RAM stick. Now I have 8GB total. I changed /etc/sysctl.conf as mentioned above ant the problem is solved.

Nicolas_Raoul (nicolas-raoul) wrote :

Reproduced every time on fresh install of Ubuntu 2015.10 on a Thinkpad T550 with 16GB of RAM, all settings by default except a few Unity tweaks, freshly rebooted.

When transferring a 364GB file, Ubuntu becomes extremely unresponsive. Mouse very difficult to move but I managed to click Firefox&s icon, it opened after a few minutes. On the opposite, I was unable to open a terminal despite clicking its icon several times, not sure why. The copy happens nonetheless, at 100 MB/second, and after it succeeds Ubuntu becomes usable again.

Nicolas_Raoul (nicolas-raoul) wrote :

Regarding my comment above: I realized that my problem happens also without any USB, just on the local disk, for instance when extracting a big tar file or deleting a directory that contains many files. Sorry if it is a different bug. Merlijn Sebrechts, do you observe the same problem on the local disk only?
Also, I have found a workaround: Whenever manipulating a big file, throttle disk usage by running commands in conjunction with `pv -L 5m`, the operation will take more time but at least the system will not hang.

Fran (rsfmcj) wrote :


Same problem in my Dell Latitude D820, Centrino Duo, 32bits, 2GB RAM. Running Ubuntu Desktop 14.4 LTS.

After trying to copy 10GB data from my local SSD to a USB hard disk, the system freezes.

Fran (rsfmcj) wrote :

More feedback about the problem I'm experiencing.

First some data about my system:

Kernel 3.16.0-57-generic
Ubuntu Desktop 14.4 LTS
32 bits
Centrino duo

I complete my previous comment. I was performing two I/O operations before I got the problem. I couldn't repeat the problem with the first one (that I described in comment #14), but It's always repeatable with the second one. That is:

1. Connect two USB disks to my computer to make a copy from the first one (say disk A) to the second (say disk B). The amount of data to copy is 80GB.
2. Start the copy from USB disk A to B. After 75% copying, the copy seems to be stopped.

The progress bar in "copy files window" doesn't move. You can close the window by pressing "x" with the mouse pointer. You can try to shutdown the system by pressing the "Shut down..." menu option, but it doesn't respond and system keeps online. Launcher bar doesn't repond.

I have by default the next values for dirty_background_ratio and dirty_ratio:

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

It seems to be that, during the huge copy from disk A to B, memory has reached the 10% of dirty pages indicated by vm.dirty_ratio. After that all I/O operations became synchronous and block the system until dirty pages a written to disk. It's just a supposition. Pending to chek it by increasing vm.dirty_ratio (so I allow the system to performance more asynchronous writes before they block the system) and repeating the copy.

When copying a large amount (multilple files) form an external drive (USB3 cable), my brand new Lenovo T450s laptop (20GB RAM, ... high specs) has frequent latencies/freezes. Doing nearly any operation takes several extra seconds, with zero responsiveness (e.g. trying to move mouse or switch to tty screen) in the mean time. Quite unusable. This is under the latest 15.10.

snapy (sdfjsfjaei-hans) wrote :

This also happens in 16.04 LTS when moving files. Mouse is very slow. Sometimes it doesn't move for many seconds.

The problem is worst.

If you plug an USB external HDD and if have REALLY bad read problems (the drive in question is damaged and i'm trying to recover some data with ddrescue) in 120s, even if there is ANY disk, RAM or CPU load, the systems crashes EVERY TIME.

I try JUST TO PLUG this specific damaged drive in 6 servers and ALL just crashed after 2 minutes!

Matthias Niess (mniess) wrote :

This problem started ocurring for me when I moved to 16.04. I also upgraded my RAM from 8 to 16GB.

Dmitriy (dimka-karp) wrote :

The problem still exists in 16.04. And as I can see the ticket is not assigned to anyone...

Saravanan (saran2somu) wrote :

Same problem in my Laptop and PC also I have used Ubuntu 14.04 LTS version, both have 8 GB Ram, while coping 3GB file (a single Movie) to my mobile sd card or My 1 TB western external hard drive the system hangs and mouse pointer not moving . After restart the system only , system will normal.

gladsonvm (gladsonvm) wrote :

I am facing this bug. I tried to copy about 100GB to a toshiba portable hdd on ubuntu 16.04LTS live, and the whole laptop got frozen for more than 20 mins. But the lights that indicates disk activity on laptop and portable hdd is blinking. even right click was not working. I noticed this bug first when I tried to move about 100GB of data from /home/user/Documents and /home/user/Downloads to a portable wd passport drive. Whole thing was slowed down but for some seconds only and I didnt take it seriously.

Also I got a kernel update on my desktop yesterday. Does this new update solves his issue?

Mauro (mauromol) wrote :

I also experience this problem on Linux Mint 17.3 KDE (based on Ubuntu 14.04), copying through the KDE I/O subsystem (Dolphin or Krusader). So, I think Nautilus (which shows in the "Affects" field) is just a victim.
I have a notebook (HP ProBook 450 G1) with 4 GB RAM. I was thinking it might have been a problem with my laptop chipset (some sort of a bus saturation problem), but I see many have the same problem and that there's a workaround (I'll try as soon as possible).

Any official statement from Ubuntu developers?

aliiv (aliiv) wrote :

Also can confirm this bug on ubuntu gnome 16.04. didnt experience it on 15.10.

Copying big files to usb thumbdrive makes system hangs on unresponsive. very annoying

Paul (paul1965) wrote :

Same problem here, driving me crazy because it's unpredictable. Last night I copied 500GB (movies 1-2 GB) from an old external HDD to a new external external HDD. Finished the next morning without problems. Next I wanted to copy 5GB and the transfer became slower until it came to a halt. The system (Ubuntu 14.04) froze, I could't use the mouse/keyboard. Had to reset my computer at the risk of damaging the disk. Luckily that didn't happen. Tried a couple times but the system kept on freezing. Had to use Windows to get the job done.

123vier (flowrist) wrote :

This is still the case on 16.04.1.
System is a Laptop with an older Core i5, 4 GB RAM. While transferring some 200MB files the system is completely unusable.

At this point it's a little embarrassing not to be able to transfer files to a USB drive without getting system freezes in 2016 on a fresh install.
The workaround (vm.dirty etc) should not be necessary.

Arno Mühren (arnomuhren) wrote :

I can confirm this is the case on 16.04 too, using an external USB SSD.
This is on a Lenovo Thinkpad X220, Core i5, 8GB RAM.

Quentin Engles (hollowdoor) wrote :

This also happens for me, but it also eventually crashes my computer (AMD Athlon(tm) II X2 250 Processor × 2 with 4GB RAM).

Michael MacEachern (maceach-b) wrote :

I'm having this issue right now on 16.04. What's strange, is that if I copy say 600GB worth of thousands of files, about half way through, Xorg will start chewing up resources, and everything slows down to a hault, even though literally the only thing I ever opened was Nautilus. I never opened Firefox, or anything elses. Straight boot to the file manager to copy files. It's a weird issue to say the least, because I can't determine why Xorg would be freaking out on large file copying. If the files finish, the performance is still poor until I reboot the machine.

Ivan Prisyazhniy (john-koepi) wrote :

Having too on desktop ubuntu lts 16.04.1 with usb 3.0, new hdd, ntfs. Also, speed continuously slowing down and then freezes and power led of the disk start flapping.

John Mapp (spidermonkey2012) wrote :

I am running Mint 17.3 on an ASUS N550JX, am also having this issue. But the fix noted above did not resolve my problem.


vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

in /etc/sysctl.conf
and running sysctl -p

Is there any other information regarding this issue? I see this issue when trying to transfer 10GB+ QEMU images.

John Mapp (spidermonkey2012) wrote :

Update: I applied the settings from the duplicate bug workaround, and that seems to have help a little. But still not 100%

vm.dirty_ratio = 60
vm.dirty_background_ratio = 40

Julie Brandon (jewelie) wrote :

Seeing the same problem since upgrading from 15.10 to 16.04.

The vm.dirty workarounds and disabling swap don't make a difference.

Once this problem kicks in ALL disk writes become stupidly slow (2MB/s) until next reboot on both SSD and spinning HDD.

i5-4460/16Gb RAM/ASUS Z97-K

This is an enormous problem not to have at least been assigned to someone!

ullix (ullix) wrote :

Same problem on Ubuntu Mate 16.04.01 with caja, nautilus and nemo.
Moving only a few dozen files can take several minutes. Files are on one disk in same directory tree.

Moving files with mv is almost instantaeous, too fast to measure.

Intel i74771 and SSD and HDs

Still having these slow USB performances after updating to Ubuntu 16.10 - and worse, it crashes sometimes when copying large files :(

valk (vkhalil) wrote :

Same here on ubuntu 16.04

GTriderXC (gtriderxc) wrote :

Slows down and hangs seem to be two different problems. My mashines never hang but "slow down" when copying thousands of different files. I found an interesting answer here:

1'st answer from izx > reason 2, that You can see in my photo. After 3 hours of copying files I copied 29,4GB from 38,7GB but ONLY 20460 from 69502 files. If there is a problem that deserves a bug report then there is one with estimating the real time.
At first system showed me 4 hours, then decreased to 2, the last hour lasted 110 minutes. Copying itself (this screenshot was taken on 2016 but from Ubuntu 12.04) is very reliable I'd say if only USB drive is reliable.

Dakota (fischmuetze) wrote :

Same here on 16.04 and 14.04 ...

I made thousand of disk performance tests and found a lot of unspecific impacts of the performance without reasonable by any other process. Although the following tests are using a LVM vol this is also happen on a "normal" single device

$ hdparm -tT --direct /dev/mapper/VGHOME-LGHOME
 Timing O_DIRECT cached reads: 2158 MB in 2.00 seconds = 1078.39 MB/sec
 Timing O_DIRECT disk reads: 2118 MB in 3.00 seconds = 705.58 MB/sec

$ hdparm -tT --direct /dev/mapper/VGHOME-LGHOME
 Timing O_DIRECT cached reads: 294 MB in 2.03 seconds = 144.49 MB/sec
 Timing O_DIRECT disk reads: 178 MB in 3.03 seconds = 58.67 MB/sec

$ hdparm -tT --direct /dev/mapper/VGHOME-LGHOME
 Timing O_DIRECT cached reads: 280 MB in 2.01 seconds = 139.10 MB/sec
 Timing O_DIRECT disk reads: 602 MB in 3.02 seconds = 199.42 MB/sec

For a long time we assume the virtual environment (VMware vSphere) but in the meanwhile I guess this is a ubuntu problem in special "hardware" environments - paired with larger volumes and a lot of inodes

this bug affect me too, ubuntu 16.04.1

i also have this bug in ubuntu 16.04.1, i have a dual boot system (i5-5200u 5th gen, 8gb). Copying files from windows directory was too slow, but it wasn't the case in 16.10.... (i had to revert because of some compatibility issues).

Ed Guenter (edgue) wrote :

Same here.

I simply stopped using nautilus file copy for *anything* that is more than 5 files and 10 MB.

Just because it is always always always much slower than anything I do on the command line.

Ive got this same issue on 16.04.02. It happens with nautilus and also rsync.
Ubuntu is installed on ssd, and so shouldn't have any noticeable impact on the file transfer, but for some reason it does...

Warick Muter (warick) wrote :

As an added note: this not just an issue with nautilus. I've experienced the same issue with thunar on Xubuntu 16.04 and kernel

Warick Muter (warick) wrote :

It seems that there is a problem with the kernel default I/O scheduler, CFQ.
The following worked for me.


Peter Stevenson (2e0pgs) wrote :

Greetings I found this to work perfect for me. This issue persits in 16.04.2 still:

My setup OS: Ubuntu 16.04 xenial, Kernel: x86_64 Linux 4.4.0-66-generic

John Quail (johnquail) wrote :

Switching to the "deadline" I/O schedular seems to have solved the problem for me

Mauro (mauromol) wrote :

I think this bug report is a bit messy, because it mixes two different issues.

I think that the original problem is the one I'm experiencing and that is perfectly described by the StackExchange answer pointed to by Peter Stevenson's comment #45.
Indeed, setting dirty_background_bytes and dirty_bytes to low values is the only way to fix the problem in my case.
Either using low vm.dirty_background_ratio and vm.dirty_ratio or changing the scheduler to deadline does nothing in my case (by the way, the suggested low values for vm.dirty_*_ratio parameters seems to have become the default at least in recent Trusty updates).

The problem described here is not just that the system is slow at copying many files, but that it stutters and completely freezes (mouse pointer included) for whole seconds, if not even minutes (last time I had to leave my PC for about 10 minutes to let a huge file transfer terminate and be able to even move the mouse pointer again... many other times I simply switched off the system and restarted). This happens when copying huge files (some gigabytes in size) to a relatively slow device, which might by a USB drive or a network drive (when using WiFi, for instance). And, even if the aforementioned reply and referenced pages talk about this happening on systems with a lot of RAM, in my case it happens even if I have only 4 GB of RAM.

Anyway, it's sad to see no words at all from any Ubuntu developer on this bug report, given that it seems to be a well known kernel issue, unless I missed something.

totally agree with mauro - it is very sad that nothing happens. if this goes on, i ll have to consider another linux OS for my next machine :(

tried all the suggestions and none worked for me. too many parameters involved, too complex, impossible to narrow down the issue.

My setup: 16.04 xenial, Kernel : Linux 4.4.0-67-generic

I agree it may be two different issues.
Since two weeks I have having a related problem, although it is no the stuttering/freezing of the system mentioned in #45 (issue 1) while copying files. No crashing when copying files, just slowness and it never used to be a problem. It started when I was copying a few large files together and continued to affect this external hd since then.

At some point copying relatively small files (say 700 mg files) to and from my WD elements 1TB external drive (even one file at the time) became incredibly slow. It is not that at some point the bar goes slower as in some versions where at 99% is seems to slow to a trickle.
It is just slow from the start and continues to be slow till the end. It is somehow related to this particular external drive since I tried other drives and they work just fine. I checked it on a Windows and again it works fine so there is no physical problem with the drive itself. I tried to delete the files, thinking that's what it is all about, but I am still left with the same issue. It is a mess.

Facundo Batista (facundo) wrote :

Yes, this issue is mixed, people talking about those two problem.

The original poster states one of the problem, though: "While copying many and large files to and from a USB drive, the system becomes incredibly slow and sometimes hangs.", which is illustrated by Mauro (mauromol) with the example of "mouse pointer freezing". I saw that too many times :(

I'd totally buy the system copying files slower if I can still use it while working.


Tommi Tikkanen (tommi-exe) wrote :

I have this problem on Ubuntu 16.04. Not only the system becomes very slow, but also the USB transfer speed is horrible. From USB3 port into USB2 drive it goes down to 2-3 MB/s

Kevin de Bie (abramech) wrote :

Seeing the same issue on 16.04 on an early 2009 iMac with 8GB's of RAM and an SSD. (the last two things are unconventional for this model, as is the prescence of Ubuntu instead of OSX i guess)

The workaround proposed in asnwer #6 seems to at least prevent my system from locking up during file transfer. (so far)

max (max-illis) wrote :

I have this on ubuntu 17.04. It's very annoying; every time I copy large files to/ from a USB drive the PC slows/ stutters until the copy has finished

And I find it very surprising that this bug is still not assigned despite being confirmed

Ihor Menshykov (ihor-ibm) wrote :

Same here on 16.04 with 64 GB of RAM.

Ihor Menshykov (ihor-ibm) wrote :

Same also happened to me on all the previous versions I used - 14.04, 14.10. Considering switching to a normal Linux who's core doesn't work like shit.

szemy (sz-tomika) wrote :

Same here, 8Gb Intel Core 2, copying ~5Gb to usb, even mouse pointer slows down. Tried it with 4.10 kernel, same happens.

Laurent Dinclaux (dreadlox) wrote :

16.04 64bit 4.8.0-54-generic #57~16.04.1-Ubuntu affected too. N551JK (ASUS-NotebookSKU)

The workaround in #6 doesn't fix the system being very laggy while copying files over USB. Maybe a tad better but huge lags still happen.

GRbit (grbitt) wrote :

Problem starts with 4.10. Previously used 4.4.

Monk (monk-fgh) wrote :

I'm using 16.04 and I have the same problem.

I think nobody mentioned that: the real problem may be that the speed is not displayed accurately. I have a USB flash drive where copying a 3GB file takes around 8 to 12 minutes (in Windows the copying speed is up to around 10Mb/s). In Ubuntu it takes the same amount of time but it gets to 100% really quickly and then I have to wait until it's actually done.

levien (levien) wrote :

Could this, at least in part, be a duplicate of this bug?

Matthias Niess (mniess) wrote :

@levien: I think people might be mixing both bugs up, but as I mostly use the terminal for copying and moving, I can assure you this is its own bug.

zzarko (zzarko-gmail) wrote :

I'm not using nautilus, but I'm still affected. I'm having a system slowdown even when copying files over 10Mbit network, so it may be not just USB related. Generally, when some I/O is at its full capacity (being that slow USB 2.0 or slow 10Mbit network transfer), the whole I/O of the OS comes to a crawl. For example, if I copy a 1GB file over 10Mbit network, until that copying is finished, everything disk-related is slowed down (stating of programs, opening files). I have 3 hard drives in my computer, if I copy something from second to third (OS is installed on first), starting programs is still slowed down, although drive holding the OS and programs isn't participating in file copying.

zzarko (zzarko-gmail) wrote :

Sorry, not 10bit, 100Mbit...

bjv (bjamesv) wrote :

Suffering badly on 16.04 LTS, every time I need to move >100MB or so from SSD to USB2 external drives. Transfer of large files seems to block/cause Nautilus & "File Operations" dialogue to become choppy/hang.

zzarko (zzarko-gmail) wrote :

Today, while unpacking an archive of about 1GB of small files from internal HD to USB HD, I wanted to unpack a small ~50k file on the USB HD also... It wasn't done until a big archive was completely unpacked. A new low...

Thomas (ew0) wrote :

What file system is involved?
I'm still investigating, but in my case it seems always btrfs related so far.

VESELIN VASILEV (vvvasilev) wrote :

I am also affected by this bug on Lenovo Thinkpad with: Intel® Core™ i7-4810MQ CPU @ 2.80GHz × 8 and 256GB SSD. But it seems it is not hardware related. Tried the workarounds, none work, the systems is still sluggish and freezing while copying (both nautilus and command line) 6GB file to USB. The copy rate is also low - towards the end just 3-4 MB/s.
The system partition is ext4, not btrfs like suggested above. The distribution is 17.04

Facundo Batista (facundo) wrote :

I also suffer this problem in non-btrfs filesystems (ext4 on hardisk, different ones when USB drive involved)

Thomas (ew0) wrote :

ok, obviously a wrong guess on my side. I tried copying from and to xfs and jfs without problems, and signs of paralysis with btrfs coming in. But if you experience sluggishness without btrfs I also doubt it's related to that.

Thomas (ew0) wrote :

Btw. I'm not using any graphical UI, just the command line.
Linux doctor 4.10.0-35-generic #39~16.04.1-Ubuntu SMP Wed Sep 13 09:02:42 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

zzarko (zzarko-gmail) wrote :

I was also using command line, everything was on ext4 (internal HD and USB HD).

Connie (diacalc) wrote :

The same here.
$ uname -a
Linux connie-desktop 4.10.0-38-generic #42~16.04.1-Ubuntu SMP Tue Oct 10 16:32:20 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

$ free -m
             total used free shared buff/cache available
Memory: 3939 3040 156 97 741 504
Swap: 3999 125 3874

rava (rava) wrote :

I am also affected , its not just nautilus, all file managers and even using VM was the same , at first I thought my hdd was dying but now I tested couple wd my passport hdd same issues

lubunut 17.10 64 bit

Ivan Borisov (borisov87) wrote :

Same problem
Kubuntu 16.04 LTS
8Gb Ram

Ivan Borisov (borisov87) wrote :

This fix my problem. Add deadline i/o sheduler for non rotating disks (in my case usb pen)

sudo nano /etc/udev/rules.d/60-schedulers.rules

and paste these

# set cfq scheduler for rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

# set deadline scheduler for non-rotating disks
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"

before change i has

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"

i don't know why. By default form ubuntu 14.4 io sheduler miust be deadline by default

but may be is not :)

Nick Smolinske (smolinux) wrote :

Same issue here on a new 16.04 install on a new HP laptop. SSD. It was crashing randomly during the install, then when I got it installed it crashed every time I tried to run the updater.

Setting the vm.dirty_ratio and vm.dirty_background_ratio to 10 and 5 worked for me as well .... so far.

I did notice one interesting thing, which I feel might help diagnose what's going on behind the scenes. When I was having the problem, the CPU temp would get pretty high (up to 70 C) and the fan on the laptop was running very loudly. These symptoms happened every time. The mouse became slower, and slower, and unresponsive. Ctrl-Alt-F1 and other keyboard shortcuts were unresponsive as well.

After changing those vm values, I was able to go through the updater with no issue. And my CPU temp was about 10 C lower, hovering around 60 during the updater. The cooling fan did not go on high either. So somehow the higher vm.dirty values are creating a situation where the CPU is working much harder than it needs to for the job it's trying to do.

I don't know nearly enough about the inner workings of linux to know what this means, but my instincts tell me it might be an important clue for anyone trying to fix this bug. Hopefully it helps.

Nick Smolinske (smolinux) wrote :

False alarm! The problem just happened again. Froze while downloading the google chrome installer.

It does seem like the vm.dirty modifications definitely helped. But it could have been coincidence. At least it didn't freeze during the updater and ruin my filesystem this time.

Ivan Borisov (borisov87) wrote :

Also false alarm for my #75 comment

Just yesterday i copy more small file 1Gb and yes also with not good speed but without slow down pc. Now i copy 2 movies x 1.5gb , and pc hang. Not possible to move mouse normal and etc.

I see this bug is from more than 2 years and not fix yet. Very disappointed :(.

q8374gf (q8374gf) wrote :

After reading all these comments, me too, etc. etc. This is what fixed it for me, although I set mine at 200MB instead of 15MB.


q8374gf (q8374gf) wrote :

I should also say that the link I posted solves a different problem. Nevertheless, it's what worked for me.

JLuc (jluc-q) wrote :

about same here with Ubuntu 17.10 : copying 700Mo file to USB, using nautilus, is apparently very quick and freezes in the end.

Ruslan Baskou (ruslan-baskou) wrote :

Solution #79 solves the issue.

aleandro (aleandrodasilva) wrote :

Solution #79 solves the issue for me too.

Ubuntu 17.10. I was trying to copy some big files in the order of 50GB to an external hd (formatted NTFS) via USB2 and noted it hung every time (I tried at least a whole afternoon). I installed caja and had the same issue like under nautilus. I have never seen this bug before although I use a lot external disks with big file transfers

Setting /proc/sys/vm/dirty_bytes to something like 200000000 (circa 200 MB) solves the problem. The original value in that file was 0. As stated in the thread that value is too small and can cause freezes of the OS. I tried a value of 15 MB too and had freezes.

The only problem now is that the value in dirty_bytes is set to 0 every boot.

roots (roots) wrote :

You can make those settings permanent by editing


and adding the line

vm.dirty_bytes = 200000000

By issuing

$ sysctl -p

you won't have to reboot to use the new settings right away.

Anyway, for me it does not make any difference transfer speed wise when copying files to USB with Ubuntu 16.04.3.


Thomas (ew0) wrote :

Maybe this helps some folks with the same issue:

On copying larger files, my system syslog showed multiple times
 usb 9-2.4: reset SuperSpeed USB device number 4 using xhci_hcd

As root the following command line fixed the issue with the usb storage driver

 modprobe -v usb-storage quirks=0x174c:0x1053:u

If that works you can persist it by entering this into rc.local or similar.


Thomas (ew0) wrote :

Regarding my previous comment - much better to add this line to a file in /etc/modprobe.d/

e.g. usbquirks.conf

Create this file and add

options usb-storage quirks=0x174c:0x1053:u

Thomas (ew0) wrote :

...and you get the HW address via lsusb (in my case 174c:1053)

Blake Riley (cerran) wrote :

I experienced this issue twice in the last 24 hours on 16.04. Both times, I waited over an hour after the computer froze before performing a hard reset on the machine. (The expected time for the operation to complete was under 10 minutes.) In my case, the computer goes directly from working as expected to being completely unresponsive, freezing all input (keyboard, mouse, power button) and output (screen, file transfer).

The bug does not appear consistently, though. After restarting the computer, performing the same file transfer worked without any issue.

kutuzof (kutuzof) wrote :

@ew0 I setup the usbquirks.conf the way you recommended. I also confirmed that the address is right with lsusb. However it doesn't seem to have had any effect. How can I confirm that it's being loaded?

I'm not sure whether the following is clear to whoever is looking into this bug: The issue arises only when using a USB3 port; it does not happen when using USB2. At least, that's the way my 14.04/12 Gb system is affected.

Vishal Kute (vishal.kute) wrote :

I've tried to copy my data (2GB)to the external drive, it takes almost 4-5Hours to finish. I'm on Ubuntu 16.04 LTS 4.4.0-130-generic

maravento (maravento) wrote :

Same problem in Ubuntu 18.04.1 x64 (Gnome and Mate Confirmed). None of the proposals described work

John Bell (jkabell) wrote :

I have run into it with Ubuntu 18.04.1 x64 also. I have a completely separate drive and Windows system in the same computer and Windows, dare I say it, has no problem and is quick. My data files that fail are 400-500MB and they freeze after about 200MB of transfer when copy from a 32GB SanDisk Ultra (80MB/s) SD card. But success with Windows tells me I don't have a hardware problem.

This bug is now more than 3 years old. Like #78, I am disappointed.

Sebastien Bacher (seb128) wrote :

Is the issue there specific to nautilus or do you have the same if you copy from a command line (using cp or gio cp)

Facundo Batista (facundo) wrote :

No matter how you do the copy, the problem presents.

Sebastien Bacher (seb128) wrote :

So even if you use the 'cp' command line tool?

Facundo Batista (facundo) wrote :

Yes. It's how I copy stuff 99% of the times, anyway.

`cp ~/movies/BigSomething.mkv /media/facundo/PenDrive/`, and the whole system starts to lag.

Sebastien Bacher (seb128) wrote :

Thanks, it's not an issue in nautilus then, reassigning to linux

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

Duplicates of this bug

Other bug subscribers