> That's one approach; I prefer my "weighted scoring" approach. Supposing we
> have three devices: a solid state disk (instant "seeks"), a hard drive and
> a tape. The SSD will benefit from merges (fewer commands to process), but
> not hugely - set both the metrics at 1, so a 64Kb request is just under
> twice the "cost" of a 32Kb one. The hard drive can seek fairly quickly,
> but long reads are preferable - say, seek_cost = 16, block_cost = 1. A
> single 64Kb request is "cheaper" than a pair of 32Kb requests, but not
> hugely so. Then the tape: seeks can take a few minutes, so make it
> seek_cost = 65536, block_cost = 1: we don't really care how much is being
> read, within reason, since seeks are so "expensive".
If we could read by a SCSI command the maximun/typical/minimum seek and
transfer speed directly from the drive things were a lot simpler :))
Bye.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Sep 23 2000 - 21:00:13 EST