Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I've noticed that when I do heavy write applications, the whole system slows down. To test this further I ran this to do a (relatively) low-CPU, high disk activity:

john -incremental > file_on_SSD

This pumps out tens of thousands of strings per second to a file on my system disk.

When it's doing this, the mouse lags, TTYs become unresponsive, applications "fade" and generally the whole computer becomes unusable. When I can eventually Control+C john, the system comes back to full strength after a few seconds.

This is an extreme example but I have similar issues with slightly less write-intensive activities like copying big files from fast sources or transcoding.

My main OS disk is a quite fast SSD (OCZ Agility 60GB) with EXT4. If I write john's output to a mechanical disk with EXT4, I don't experience the same slow-downs though the rate is a lot slower (SSD does ~42,000 words per second, mechanical does 8,000 w/s). The throughput may be relevant. The mechanical disk also has nothing to do with the system. It's just data.

And I'm using kernel 2.6.35-2 but I've noticed this issue since I got this SSD when I was probably using .31 or something from around that time.

So what's causing the slowdown? EXT4 issue? Kernel issue? SSD issue? All of the above? Something else?

If you think I need to run an additional test, just drop a comment telling me what to do and I'll append the result to the question.

share|improve this question
Maybe you should also mention what SSD are you using. Not all SSDs are equal. – Cristian Ciupitu Aug 27 '10 at 18:36
@Cristian: Added. It's an OCZ Agility. – Oli Aug 27 '10 at 22:31
up vote 12 down vote accepted

This has been a known issue for awhile. Using an SSD-tuned FS like Btrfs might help, but it might not.

Ultimately, it is a bug in the IO scheduler/memory management systems. Recently, there have been some patches that aim to address this issue. See Fixed: The Linux Desktop Responsiveness Problem?

These patches may eventually make their way into the mainline kernel, but for now, you will probably have to compile your own kernel if you want to fix this issue.

share|improve this answer
If I understand correctly, patches for this should go into linux 2.6.37. – JanC Aug 28 '10 at 13:39

There are a few things you can check on to try to improve SSD performance under Linux.

  1. Set the mount point to 'noatime'. Extra activity updating access times are generally wasted on most use cases. Especially in the case of continually pumping single lines into a file, you are forcing multiple updates to the filesystem for every access.

  2. Check the elevator. The default elevator for most distros are set up for random access spinning platters. SSD's don't need the extra logic, so setting the elevator to noop can improve performance by letting the hardware manage the writes.

  3. Write-through v write-back caching. This is a bit more esoteric, but you can check the caching method used with hdparm for the device. Write-back caching can have a positive impact on SSD performance compared to write-through.

share|improve this answer
Could you @nzwulfin write a little bit more about setting elevator ? – Grzegorz Wierzowiecki Jun 14 '12 at 7:10

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.