uldus:
> Зависимость вероятности попадания данных из кэша от объема кэша
> и параметров диска не линейная, есть оптимум, который и используют.

Расскажите, pls, как вычисляется этот оптимум. Лично мне сей алгоритм неведом.

> Кэшировать то что уже считано и то что может быть будет считано
> разные вещи. Кэш ОС эффективен в первом случае, кэш диска во втором.

Вы думаете, что диск лучше знает, что операционка будет читать в будущем? :)

> Другой контраргумент: ОС точно не знает где сейчас висит головка,
> а электроника диска знает.

У диска есть два параметра, определяющих время выполнения запроса: это начальная задержка T0 и скорость считывания/записи V (т.е. время обработки запроса объёмом N байт = T0 + N/V). Чтобы второе слагаемое стало больше первого, с диском надо общаться порциями в несколько сотен килобайт, что, IMHO, бывает нечасто.

V - это константа, на ней никакими манипуляциями ничего не выиграешь.

T0 состоит из двух слагаемых: время на перемещение головки и время на ожидание прихода под головку нужного сектора; причём второе существенно больше первого (паспортное время задержки обычно почти совпадает с полуоборотом диска).

Операционная система видит диск как линейно пронумерованный набор секторов и знает, что чем больше различаются номера секторов, тем дальше надо двигать головку. Поэтому первое слагаемое, составляющее T0, операционная система оптимизирует достаточно хорошо.

При упорядочении обращений к диску по номерам секторов (а хорошая операционка, особенно многозадачная с "умным" планированим процессов именно так и делает) минимизируется и ожидание прихода сектора под головку (для случаев обращения в один цилиндр). Так что диску тут просто нечего упорядочивать.

И наконец, последний гвоздь в крышку гроба:
Если в системе выполняются транзакции (надеюсь, никому не надо объяснять, что это такое), к числу которых относятся файловые системы NTFS (W'NT) и UFS+SoftUpdates (FreeBSD), то очерёдность записи на диск определяется программами и НЕ ДОЛЖНА МЕНЯТЬСЯ ДИСКОМ. Так что диску ЗАПРЕЩЕНО ОПТИМИЗИРОВАТЬ запись на него; а при достаточной памяти (купленной на разницу в стоимости IDE и SCSI) чтение хорошо кэшируется операционкой в памяти, установленной на мат.плате.

bass:
> По скорости работы IDE подошли к SCSI160 (r/w 55Mb/s) [ээ, 98 год помоему первый выход 160-к]. Если учесть, что на смену уже устаревающих 320-к (110Mb/s) тихо идёт 640 (сами подсчитаете?), то вопрос об использования IDE, в высоконагруженных системах (например nas на 10-20 серверов.) отпадает совсем.

О какой скорости мы говорим - о скорости электрического интерфейса или о скорости работы механики диска? Тормозом является именно механика (именно она обеспечивает T0), а она от интерфейса (IDE или SCSI) не зависит.

Конечно, в более догогие SCSI-диски ставят более качественную и быструю механику. Но если взять дорогой IDE-диск, то он будет работать так же, как SCSI, при меньшей чем у SCSI цене. IMHO.

PS: А что у вас делают в промышленных системах процессоры Xeon, которые сами греются ка муфельная печка?