Wolfgang S. Rupprecht wrote:
> Any "elevator" type
> algorithm that sorts the per-partition motion for "closeness" is going
> to clash with the same code running on behalf of the other fs
> partitions (or even swap) on that disk.
> 
> (This assumes my understanding of how things works is correct.  I
> *think* the I/O sorting is all on a per-partition basis.)

I guess this is not the case. The FS code may try to allocate blocks on 
the partition so that file data tend to be contiguous, and if not, then 
close; but the actual block operation reordering is due by the cache 
subsystem which deals with the whole device as a whole.

I may be wrong on that though - I haven't checked the source, at least 
on BSD.

mortee

-- 
The point is that, unlike a command tool for techies that should give 
them lots of choices, the goal of a GUI is to present the user with as 
few decision points as possible. Remember the Macintosh dictum that the 
user should never have to tell the machine anything that it knows or can 
deduce for itself.

	- Eric S. Raymond: The Luxury of Ignorance