up vote 36 down vote favorite
22

Yesterday I was copying a single, 8 GB file to a USB with a slow, 7 MB/s write speed, while my RAM is 3 GB. While copying the system froze, to the point where I couldn't even move the cursor.

I managed to log into the text console, and ran iotop, it showed that a process named kswapd0 was taking 99.99% of IO.

Are there workarounds so copying a large file doesn't make my system unusable?

share|improve this question
6  
This bug is so ridiculous... – king_julien Jul 2 '14 at 19:08
up vote 23 down vote

According to this bug report I solved it adding following lines

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

into /etc/sysctl.conf

and running 

sudo sysctl -p
share|improve this answer
9  
Care to explain what the above lines do? – nsane May 2 '15 at 6:39
1  
@nisargshah95 sorry, but dont have a clue, search for yourself ;-) – Philippe Gachoud Feb 15 '16 at 9:45
4  
@nisargshah95 The details of the problem are explained in the two LWN articles linked in unix.stackexchange.com/a/107722/52205 – Rmano May 15 '16 at 15:37
1  
Thank you, I just found that my Ubuntu 16.04 can not write two 1.4 GB files to USB without these two lines, I was getting frozen for hours, this solved problem, who cares what it does, sometimes you just want to copy files and move on. – Mike Aug 10 '16 at 19:29
1  
I had values of 5 and 60. These control the percent of memory used for operations, while dirty_background_bytes and dirty_bytes use absolute bytes values. I've fixed this issue with second answer, but to make it persistent add it to sysctl.conf, see this answer. So when using percent values tweak them when upgrading memory. – PeterM Sep 14 '17 at 13:15
up vote 11 down vote
+50

I ran into the similar issue. Mine is 64 bit Ubuntu 14.04. So After a long struggle I found a answer which solves my issue. For easy use I added the commands below used in that above mentioned answer. Check the answer for detailed explanation.

echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

After using the above command system started to work normally on copying files.

Thanks goes to @Rmano.

share|improve this answer
2  
The ratio settings didn't help on my 12.04 system with a slow NAS share. But after setting bytes directly as suggested here my system is usable again while copying to the NAS. – mivk Dec 24 '15 at 12:04
4  
This question is 3 years old and this is still required to avoid getting an unusable system while copying to pendrive. Some info: if the pendrive is formatted using a Linux fs like ext4 this doesn't happen. When I said "unusable system" I really mean it, mouse pointer becomes unresponsive and you have to insist to move it around the screen, you look at the system monitor and there isn't any abnormal resource usage. Are the kernel people all using 6th gen Intel CPUs and SSD drives? How come they don't notice this while testing. – Hatoru Hansou Feb 22 '17 at 13:03
3  
@HatoruHansou I feel the same, I just installed fresh Debian Stretch and this error is present here also. I know it does not depends on distribution, but on kernel sources, but men, how come this is still not fixed? – Marecky May 19 '17 at 15:20
1  
@Marecky After some reading it seems that the dirty_bytes aren't a usb thing alone. They affect all I/O so after doing the echo thing you are changing them system global, not for pendrives alone. For the current session only, I think. It seems that kernel's current values are tweaked thinking in newer storage devices. Slow pendrives suffer as a side effect. Sorry, no link, but this must be easy to find by googling for it. – Hatoru Hansou May 20 '17 at 1:47
3  
See this answer to make it persistent – PeterM Sep 14 '17 at 13:16
up vote 3 down vote

I experiencing similar issue with freezing system when copying to flash drive. I reported bug report about it: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648

As workaround I found, that disabling swap completely eliminates this problem.

share|improve this answer
1  
Unfortunately this didn't work for me on Ubuntu 16.04. – Programster Jun 4 '17 at 17:23
    
Didn't work for me either on Ubuntu 16.04.3 LTS - this on an Alienware 17 R2 laptop. – AnthonyK Nov 17 '17 at 7:36
up vote 3 down vote

Yes, there are kernel settings you can tweak specifying how much data has to be marked as written before it actually gets written to disk. Look here for a pretty comprehensive description of them. In particular, you'll want to find a value of dirty_ratio that works well for you (it's generally too high for desktop/laptop by default, but there's no one magic number that works for everyone).

share|improve this answer
2  
Hey, could you please suggest me what numbers I need to set based on my laptop specifications ? refer askubuntu.com/questions/713723/… – user441517 Dec 28 '15 at 19:21
up vote 1 down vote

I had similar problems when copying files to an exfat drive. I had less trouble using an ext4 filesystem on my USB hard drive .

share|improve this answer
1  
Had this issue on ext4 too – PeterM Sep 14 '17 at 13:01

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.