|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 01 Dec 2003 22:12:36
To : Dmitry Astapov
Subject : Re: дефрагментация ex3
--------------------------------------------------------------------------------
>>> Dmitry Astapov wrote:
ID>>> В многозадачных системах тебя спасут SCSI винты. Они умеют ставить
ID>>> запросы в очередь и "интелектуально" выбирают какие удобно выполнить
ID>>> подряд.
OG>> Кстати, а что мешает делать такое софтово? Добавить ещё один layer,
OG>> который будет именно тем и заниматься - упорядочивать обращения. Как
DA> Ключевой вопрос - упорядочивать как? Телепатически узнавать у винчестера,
DA> какие секторы "близки" друг другу, а какие -нет? Хинт: из геометрии,
DA> размера винчествера, абсолютного номером сектора, который надо считать, ты
DA> этого никак не узнаешь.
Заблуждаешься. Для винчестера, кроме случаев ремапленных секторов, чётко
выполняется простое утверждение: если A<B, то C(A)<=C(B), где A, B -
номера блоков, а C(A), C(B) - физические цилиндры, на которых
находятся эти блоки. Этот принцип устойчиво поддерживается производителями
и, я предполагаю (хотя не уверен), внесён в отраслевые стандарты.
Поэтому, лифтовый оптимизатор - алгоритм расписывать не буду, думаю, ты
и из названия его поймёшь - приводит (опять же с поправкой на ремапы)
к минимизации перемещения головок. Есть математическое доказательство -
я его, sorry, не помню - что это таки оптимальный алгоритм в среднем по всем
видам потоков; он минимизирует сумму времени отработок отдельных запросов
и при этом корректен, то есть гарантирует конечное время отработки каждого
запроса.
В linux по крайней мере в 2.4 есть лифтовый оптимизатор, AFAIH.
Дальнейшей оптимизацией могло бы быть упорядочение запросов, включающее
учёт оборота диска. Hапример, этим занимался драйвер UFS в старых BSD
системах. Hо так как сейчас физическая геометрия диска напрямую недоступна,
то такую оптимизацию не делают, несмотря на то, что времена позиционирования
через весь диск и время одного оборота поверхности сравнимы до пол-порядка,
и при доступности физической геометрии здесь было бы большое поле
для оптимизации.
Разумеется, даже с такой оптимизацией диск работает медленнее, чем в случае
TQ (SCSI - практически всегда, ATA - у отдельных производителей). И ускорение
в варианте с TQ идёт из трёх источников:
1. Трансляция LBA (linear block address) в физический геометрический адрес,
учитывающий ремапы.
2. Оптимизация с учётом и скорости вращения, и скорости перемещения головок.
3. Последнее по порядку, но не по важности - более плотное использование
шины контроллер<->диск. В случае отдачи команд по одной там обязательно
есть задержка на каждое чтение (без кэша). В случае очереди команд,
пока одни ждут результатов, от других уже отдаются результаты.
В некоторых случаях ускорение тут может быть даже в разы - кстати,
именно разы (~2) я насчитал дома на ICH2 + IC35L040AVER07 + FreeBSD4
(тестом была компиляция).
-netch-
--- ifmail v.2.15dev5.1
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
