Re: O.T. optimising file placement
On 02/22/2012 05:31 PM, Martin Gregorie wrote:
On Wed, 22 Feb 2012 14:27:17 -0800, Lew wrote:
Modern hard drives, pretty much all of them, have a buffer and
microprocessor as part of the hardware. We're not going to get any
"Marthaing" as you describe it (wherever the heck /that/ term came from)
because what they're already doing is already so effective.
What they mostly do is collect read and write requests and combine them
in elevator-seek order, along with full-track readahead. This optimizes
disk access for single sweeps of the drive heads.
Agreed, and a mainframe OS I was using in the early '70s (ICL's George 3)
was doing it back then and very effective it is too for speeding up disk
access. Back in the day it pushed the speed of the 2800 rpm, 60 MB
washing-machine sized disk drives up from around 8 accesses/sec to
something like 20-30 per sec.
However, its ineffective unless there are many active processes
simultaneously requesting disk i/o. If all the requests come from one
Spurious point, and not entirely true. It's effective if many requests come in
between I/O activity windows regardless of how many processes are involved.
single threaded process then it can't optimize head movement because
there's never more than one pending request at a time. I know this is
Except for when there is. Also, consumer OSes like Windows are always running
multiple processes, most of them in the background like, oh, the Windows
indexer which is a big consumer of I/O services.
reduction ad absurdam, but it does make the point that a small active
process population is unlikely to be optimised as well as a large one.
It's a spurious point because who needs to optimize a slow, single-process
scenario?
This is relevant today for allmost all single-user workstations
regardless of whether they are running Windows, Linux or OS X. Since the
You mean irrelevant.
First of all, single-user does not mean single-process. All these systems are
multiple-process with multiple processes at all times.
Second, if the system is so light on demand that you don't benefit from
elevator seeking and on-disk cache, why do you care about moving tracks or any
other optimization? You don't compare race cars to beetles by saying that the
performance enhancements in the race car don't matter to street driving.
majority of applications run on these machines are single threaded, about
Show us some data. Please don't throw around terms like "the majorit of
applications [that] run on these machines" unless you have data.
This point is highly disputable. I've looked at "top" and the Windows System
Manager and seen many poly-threaded or poly-process processes running. I've
never run the numbers to see which are in the majority, nor quite sure what I
would define as "majority" in that circumstance.
Do you weight them, say by giving virtual memory a very high weight? Oh,
yeah, remember virtual memory? Now there's a multi-threaded, high-priority
consumer of disk.
In any event, enough processes in consumer or, as you call it, "single-user"
stations are concurrent and disk-hungry to make it plausible that elevator
seeking and track buffers will benefit even such systems.
the only time you have more than one process accessing the disk is when
the user is hammering away at a task, be it wordprocessing, spread-sheet,
browser or IDE and the mail reader, sitting in the background, finds some
mail waiting.
I think we can all agree by now that that is not true.
The on-drive buffer
also holds enough data for most reads and writes, overtaking any
advantage that any (perforce extremely slow) physical re-ordering of the
tracks could accomplish.
Yep, the on-drive buffer will almost always be capable of holding several
physical tracks and, in addition, on a *NIX system anyway, all RAM not
occupied by running processes and their data will contain disk buffers.
--
Lew
Honi soit qui mal y pense.
http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg