Sounds like disk optimizations would help that system.
Probably not - they are all cron jobs and hence get run sequentially.
In your particular case you have no need of optimization of your disk
processes. You don't mention it but by omission I will grant you that
virtual memory on your system does not seriously contend for disk
either.
Well spotted. My type of load almost never swaps. That was the case with
the old 512 MB RAM box and is double true with its replacement (4 GB
RAM), but that still doesn't stop me setting swap space at twice RAM.
In fact the only program I have that does use gobs on RAM is a JavaMail +
Postgres app and I'm not sure if its a problem due to JavaMail's queueing
or if I've got overly long lived Object instances. Tracking this down in
on my to-do list. All I know at present is that the same program using
the same JVM uses gobs more RAM on the new machine (which is 6 times
faster as well as having 8x more RAM), so it might simply be a case of
persuading the GC to run more often.
But a typical consumer scenario is to listen to a stream while
surfing the web on Windows with several chat windows open, causing
multiple disk IO ops on a constant basis of themselves and also putting
pressure on virtual memory. Even such a single-user system can benefit
from elevator seeking and on-disk buffers.
I'm not saying head movement optimisation is a bad thing, just that it
can be difficult to get enough queued requests for it to work without a
large population of active processes that all do a lot of disk accesses.
You may well be right about the typical consumer setup: I lack any
experience that: all I understand is the pattern that my own use pattern
generates. However, I would point out that streamed music or video may
never touch the disk (though of course a torrent will). The amount of
disk i/o due to chat/IM/Twitter/web browsers may be less that we'd expect
because its (a) very bursty and (b) disk i/o time is vastly outweighed by
human reading and typing time.
Consider also that burstiness of demand does not argue against the need
for optimization, really. During bursts the optimization helps, and a
user might complain if their disks got weird once an hour.
Sure, but the user's activity scan and resulting interaction with one
program at a time, which may well be single threaded, for a few minutes
before switching to another. This tends to produce widely separated
bursts of i/o from one or two processes.
Regardless, if you don't need optimization why worry? It's like the Pope
comparing brands of condoms.
Like it!
Again, we don't excoriate the value of optimizations by citing examples
where optimization isn't needed. We evaluate optimizations by how useful
they are when they are needed.
I wasn't intending to do that, having seen just how well head scheduling
works. I merely intended to point out that there are corner cases where
such algorithms don't help - but are not a hindrance either.