Sign up ×
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.

When I copy files to and from USB devices (camera, HDD, memory card) my system becomes very slow. For example if I want to close a window I move the mouse but it takes about 2 seconds or more before the mouse cursor moves. When I finally get the cursor over the x and click it nothing happens for 10+ seconds. I've tried this with all desktop effects disabled but the issue persists.

Software: Linux Mint 9 KDE Hardware:

  • Asus SLI motherboard
  • NVidia 6600 GPU
  • 2 GB Ram
  • 2 GB Swap
  • AMD Athlox X2 @ 3800+

To me this hardware should not have any issues running this software and it doesn't until I copy files using USB. Where should I start looking to figure this one out? I'm kind of thinking the graphics driver may be part of the problem but I don't know for sure.

share|improve this question
check that the USB ports are USB 2.0 capable. some USB ports, particularly on the front of desktops used to be USB 1.0 only. Also check that your BIOS settings are optimal for USB performance. There may be some USB speed settings, and/or USB legacy settings that may affect your performance. – Tim Kennedy Oct 20 '11 at 20:06
Is the device formatted as NTFS? If it is, I'd try reformatting it as FAT32 (or EXT4 if you're only planning to use it on Linux). – RobinJ Nov 6 '11 at 9:14
There seems to be a problem with huge pages in linux' memory management. It rarely occurs, but sounds like you have observed it. – artistoex Nov 18 '11 at 15:59
@artistoex - That article completely sums up the behavior I was experiencing. Too bad there is no concrete fix. Anyone know if this is fixed in later versions? Time for an upgrade anyway. – John Nov 25 '11 at 16:39
as the article says, recompile your kernel with the transparent huge pages feature disabled. – artistoex Nov 26 '11 at 11:22

3 Answers 3

up vote 5 down vote accepted

There seems to be a problem with huge pages in linuxes memory management. It rarely occurs, but sounds like you have observed it.


This is my grossly simplified account of what, according to the article, happens.

If unlucky, a process gets stuck the moment it issues a memory access. That's because when transparent huge pages is enabled, a memory access may trigger synchronous compaction (defragmentation of main memory,) synchronous meaning the memory access does not finish before the compaction does. This in itself is not a bad thing. But if write-back (of, e.g., buffered data to USB) happens to take place at the same time, compaction in turn is likely to stall, waiting for the write-back to finish.

So, any process could end up waiting for a slow device to finish writing buffered data.


Upgrading main memory, as the OP did, might help delay the problem. But for those who don't consider that an option, there are two obvious workarounds. Both involve recompiling the kernel:

  • disabling the transparent huge pages feature
  • applying Mel's patch as mentioned in the article
share|improve this answer

This sounds similar to my question here (where an answer pointed me to this question):

But the theory is completely different, and the solution I used is unrelated to yours, but works perfectly.

I was using rsync, so all I had to do was use the --drop-cache option. (which makes the copy a bit slower as a side effect)

share|improve this answer

Try removing the flush mount option if it's on there by default.

You can add your own entry in fstab for the device that doesn't have the flush option (note in doing this you need to make sure that it's sync'd prior to removal, just make sure you run sync and see it finish once before you remove it).

E.g. fstab entry
UUID="AFA2-AE87" /mnt/fuji vfat uid=1000,gid=1000,fmask=0022,dmask=0022 0 0

Change the UUID to the UUID of your device as found in sudo blkid.
Change the mount point from /mnt/fuji to wherever you want it mounted.
Change the uid,gid to match the user uid/gid as found by getent passwd <your user>.

Then unmount the drive and run sudo mount -a to remount it from the new fstab entry and test it out with dd (e.g. dd if=/dev/urandom of=/mnt/<your mount point>/bigfile.tst bs=1M count=500).

share|improve this answer

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.