The Linux disk scheduler: it sucks sticky balls

The whole point of scheduling a resource is preventing starvation. What happens when your disks are backlogged in requests? I'll tell you what: your machine dies.

Copying files and using the computer should not be painful rocket science

You see, modern operating systems don't just let programs blindly use the disk without arbitrating who gets to go first. Linux is no exception -- the disk I/O scheduler attempts to balance even request distribution between process against maximizing throughput (the actual amount of data delivered).

We in the desktop camp couldn't care less about throughput, of course. OK, we do care a bit about it, but if we're copying a 40 GB file from disk A to disk B, we sure as hell will want to use our computer productively while the copy is going on, don't we?

Linux CPU scheduler: actually kinda nice

While the Linux CPU scheduler does a somewhat non-pathological (you could even say a good) job, the disk scheduler sucks SMELLY, MUSKY NUTS.

I/O schedulers... I demand a refund!

I learned to tolerate the slow application startup times in my last computer (a not-too-slow 768 MB + 320 GB disks Athlon XP machine). I guess "userspace is pathological" like Ingo (or Con) said. But I could never understand the two big psych breakdowns my machine experienced frequently:

Big file copies

Copying a big 2 GB file between two disks is enough to throw the desktop into an unresponsiveness fit that lasts for a good few seconds after the file has been finished copying, makes mouse pointers jumpy, and task switching impossible (you can switch among tasks, however you won't see anything but a grey rectangle while the system is busy attempting to swap a few pages in from disk into the application's physical memory space, lagging behind hundreds of requests in the disk request queue).

Backups!

rsync processes: don't get me started please. Every time I run a backup, it trashes the disk caches and pushes applications to swap. I don't know exactly how, but after running an rsync of my whole /home partition, the system stays in a state that could be accurately described as "between stupid and lazy". Actually attempting to start an application while the rsync process is reading from disk... why bother -- Akregator takes over a minute just to show up!

Why I classify them as pathological cases

Both cases almost unversally exhibit the same symptom, which I'm going to term "the grey rectangle of death" -- applications don't redraw their screens until each and every essential code/data page has been loaded from swap; and that, my friends, can take almost 30 seconds for some applications.

These two pathological cases unfortunately find themselves replicated in almost every modern Linux desktop. As far as I recall, the disk IO scheduler works in fixed priority rings -- applications that hog the disk don't get demoted in priority, and in fact I think they get an interactivity bonus for constantly blocking on I/O. (At least) a desktop machine should never do this -- it should make requests for interactive applications (defined as "applications that haven't caused a page fault or disk access in a long time") literally jump the queue in front of disk hogs. Yes, that would kill server throughput -- but we're talking about a desktop machine, aren't we?

ionice as the solution?

Get real, dude. ionice is feasible for an automated backup procedure, but I don't want to type a UNIX command every time I drag and drop an episode of House M.D. to file in the right folder. That's a job for the computer. And, ideally, a job for the disk scheduler, not an external program that reacts slowly using out-of-date information.

Give me responsiveness, goddamnit. I don't care if the file copy or backup drops to 20 KB/s, so long as Konqueror starts in under two seconds. Both the file copy and the backup will finish on their own time.

My quick fix

Here is it. Should make your machine more responsive. Getting a new machine may also help.

I still maintain I shouldn't have had to get a new computer in order to solve mitigate disk starvation issues. And yet, I did:

Good news for me -- I got myself a PowerEdge 1U server with 2 400 GB SATA disks, RAID1ed, as a desktop machine. Dual Core x64 and all the bomb. It was kind of hard to set up using a KUbuntu Live CD (no LVM2 or mdadm tools included, and please note that all my filesystems are in LVM volumes now).

But it screams. It's brutally fast. Minus, of course, audio, decent video, DVD, and TV capture card, all handily virtualized through my home network for the time being. Thanks, PulseAudio!

Finally, OpenOffice warm-starts in under three seconds. Before that, I dreaded receiving a PowerPoint presentation -- and now I find them tolerable! And multi-gig file copies/rsyncs have become a bit faster.