>>
>>but seek time is some combination of headswitch time, rotational
>>latency, and actual head motion. the first three are basically
>>not accessible in any practical way. the latter is easy, and the
>>
> Yep which is one reason why I don't think being fancy will pay
> off (the other reason being that even if you did know the parameters
> I don't think they would help a lot).
The graphs in the "skippy" disk benchmark paper are
interesting -- some disks show bizarre peaks and dips in their
times across increasing sector distances. (The lesson here might
be to test your disks and avoid the bad actors rather than try
to compensate for their behavior, though.)
> There is (in AS) no cost function further than comparing distance
> from the head. Closest forward seek wins.
The RAID1 code has its own scheduler that does similar things. Why
aren't they being integrated? (See raid1.c:read_balance())
-- Chuck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/