Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I have a really strange situation here. My PC works fine, at least in most cases, but there's one thing that I can't deal with. When I try to copy a file from my pendrive, everything is ok -- I got 16-19M/s , it works pretty well. But when I try to copy something to the same pendrive, my PC freezes. The mouse pointer stops moving for a sec or two, then it moves a little bit and it stops again. When something is playing, for example, in Amarok, the sound acts like a machine gun. The speed jumps from 500K/s to 15M/s, average 8M/s. This occurs only when I'm copying something to a pendrive. When the process of copying is done, everything backs to normal.

I tried everything -- other pendrive, a different USB port on front panel or those ports from back, I even changed the USB pins on motherboard (front panel), but no matter where I put my USB stick, it's always the same. I tried different filesystem -- fat32, ext4. I have no problem with the device on Windows, on my laptop. It has to be my PC or something in my system. I have no idea what to look for. I'm using Debian testing with standalone Openbox. My PC is kind of old -- Pentium D 3GHz, 1GiB of RAM, 1,5TB WD Green disk. If you have something that would help me to solve this issue, I'd be glad to hear that.

I don't know what else info I should provide, but if you need something, just ask, I'll update this post as soon as possible.

I tried to reproduce this problem on ubuntu 13.04 live cd. I mounted my encrypted partition + encrypted swap and connected my pendrive to a usb port. Next I tried to start some apps, and now I have ~820MiB in RAM and about 400MiB in SWAP. There's no problem with copying, no freezing at all, everything is as it should be. So, it looks like it's a fault of the system, but where exactly? What would cause such a weird behavior?

share|improve this question
When I encountered something similar to this it was because I had hard drive issues on my laptop. The disk had some bad areas and every time I was trying to read anything from those areas it would freeze until it was done. Just an idea to look into. Maybe you have bad sectors where you're trying to read from. –  slybloty Jan 3 at 16:22
My hdd is ok, at least smart say so (after full scan). –  Mikhail Morfikov Jan 3 at 16:26
Try reducing the IO priority of the copying process, e.g. ionice -c3 cp something.tgz /media/pendrive. This will put the newly spawned cp process in the third (=lowest) priority class "idle". –  n.st Jan 3 at 18:00
I tried this, but it has no effect. –  Mikhail Morfikov Jan 3 at 18:22

2 Answers 2

up vote 16 down vote accepted

Are you using a 64-bit version of Linux with a lot of memory? In that case the problem could be that Linux can locks for minutes on big writes on slow devices like for example SD cards or USB sticks. It's a known bug that should be fixed in newer kernels.

See http://lwn.net/Articles/572911/

Workaround: as root issue:

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

I have added it to my /etc/rc.local file in my 64bit machines.

TANSTAAFL; this change can (and probably will) reduce your throughput to these devices --- it's a compromise between latency and speed. To get back to the previous behavior you can

echo 0 > /proc/sys/vm/dirty_background_bytes
echo 0 > /proc/sys/vm/dirty_bytes

...which are the default values, meaning that the writeback behavior will be controlled by the parameters dirty_ratio and dirty_background_ratio.

Note for the not-so-expert-with-linux people: the files in /proc are pseudofiles --- just communication channels between the kernel and user space. Never use an editor to change or look at them; get instead a shell prompt --- for example, with sudo -i (Ubuntu flavors) or su root and use echo and cat).

share|improve this answer
I have 64bit but only 1GiB of RAM, and I have to tell you this solution works! I've just tested it, and after setting the two parameters, there's no freezing anymore. :) –  Mikhail Morfikov Jan 3 at 19:10
+1 - It worked fine. !!! Thank you so much. It was a real head ache –  Abid Rahman K Feb 16 at 17:26
+1: it worked perfectly for me too. I always wondered why my system became unusable when copying stuff to an external HDD, now has a workaround. –  Renan Mar 8 at 1:59
Do I need to restart the PC after running these commands? –  becko Aug 7 at 15:07
How can I revert this change? Does anyone report a decrease in copying speed after applying this fix? –  becko Aug 7 at 15:13

hardware vs. software

I've run into strange problem similar to this with USB thumbdrives, and in my research it's almost always either a driver issue or the specific hardware within the PC/Motherboard.

I know this because I've got several systems that are identical hardware, and on one, I can do this operation without issue, while on another the problem shows up.

What to do?

You options are really limited here. About the only things you can do are make sure you have the latest BIOS/firmware installed on your system, and make sure you have the latest versions of your disto's packages.

Beyond that all I can suggest is making sure that you avoid this situation by not attempting to copy files while another copy is in progress.

If you have the type of personality where things like this irk you, you could try another live distro of Linux and repeat the steps that lead to your problem. This would just eliminate whether it's a distro specific issue or a hardware issue as I've described above. It would be a small consolation, but I always like to know things rather than bury my head in the sand, and not.

Anything else?

If you're truly obsessive you could try running the application that you're doing the copy with through strace in the hopes of catching the system in whatever system call is freezing. You should be able to do this from the command line as well.


$ strace -o cp1.log cp -r /path/to/dir1 /path/to/usb/. 

Then while that's running start another one.

$ strace -o cp2.log cp -r /path/to/dir2 /path/to/usb/. 

The system will hopefully freeze during this operation and maybe you'll get lucky and find some smoke in either of those log files.

share|improve this answer
I always use the only one instance of file copying. I have BIOS updated (2008), and there's no newer version since then. I think it's not the BIOS. My debian distro is also updated to the testing branch. I tried using strace and it starred freezing almost instantly, so I waited a few sec and killed the process. I got 1Mb log, but I can't read it, I don't know what to look for. You can check it here pastebin.com/u29RvqgC -- it's not the full log (limited to 500Kb), but there were only similar lines to those at the end. I will try to reproduce this issue with ubuntu live cd. –  Mikhail Morfikov Jan 3 at 17:08
I updated the question as to live cd testing. –  Mikhail Morfikov Jan 3 at 17:51
@MikhailMorfikov - I think you're pretty much at the end of what you can expect to do. Your hardware is pretty old (2008) and there's really not much else you can do beyond what I've outlined above. –  slm Jan 3 at 18:03
But even older pcs are able to copy files without problems. –  Mikhail Morfikov Jan 3 at 18:20
@MikhailMorfikov - Age isn't the only factor, but the likely hood of getting any updates to firmware or updates to software for old hardware is low, is what I meant. –  slm Jan 3 at 18:22

Your Answer


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.