> This would be trivial if the real disk geometry was simple, without
> variations in the number of sectors per cylinder. It isn't so though.
> Manufacturers can sometimes fit more sectors on the outer cylinders,
> this gives faster transfers and more data in those areas. Figuring
> out the real geometry with timing tests is not simple in this case, there may
> be lots of different sector counts and you have no idea where they change.
>
> You would need to do timing tests on every physical cylinder (not
> knowing where they start in the first place) and build a big table.
> Not something we want during bootup. And timing could go wrong
> if anything else happen with the machine in the meantime.
You don't even know how the mapping logical to physical block works exactly
in some cases. IBM has some series of drives that do faster track-to-track
steps than switching between heads on the same cylinder. As a result
transfer rate benchmarks on various sector ranges result in a sawtooth graph.
Advanced wierdness: Imagine one of those hardware RAID systems which look
to the host like a single block device and equipped with various types of
disk drives.
You don't want to optimize your OS for such stuff. Berkeley's FFS filesystem
used such optimizations long time ago but today they don't make sense anymore.
Elevator sorting is ok since that's stuff which is beyond what the typical
drive can do for us, so it needs help.
The one way elevator is clearly a trade off and it's a sensible one for the
average Linux system. For stuff like RAM disks or intelligent hostadapters
with currently upto half a gig of RAM on it the elevator is just a waste of
effort, the hostadapter is supposed to offload this part of processing from
the host. Since the filesystems we care about scatter data more or less
equally over the entire blockdevice as a way to reduce fragmentation I guess
a two way elevator might be a better tradeoff for disks of software RAID arrays.
Ralf
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/