Тотальная буферизация файлового ввода/вывода
В пункте 2.1.5 были рассмотрены структура оперативной памяти файлового сервера NetWare и схема формирования кэш-памяти (кэш-буфера). NetWare кеширует данные файла поблочно. Это позволяет файловой системе NetWare поддерживать тесную синхронизацию между кэш-буфером и физической дисковой памятью, что помогает обеспечить целостность данных файла и даёт большой выигрыш в производительности.
Рассмотрим алгоритм работы NetWare с кэш-памятью при чтении и обновлении блоков данных диска (рисунок 2.35).
При выполнении функции чтения данных из файла сервера операционная система NetWare рассчитывает адрес требуемого блока на диске и проверяет, находится ли он в кэше. Если да, то данные пересылаются из буфера кэша в пул NLM-модуля, выдавшего запрос на чтение. Если требуемого блока в кэше нет, и имеется свободный буфер, то блок читается в этот буфер. Если свободных буферов нет, то ОС выполняет поиск буфера, который наиболее длительное время не использовался (алгоритм LRU) и перезаписывает его на диск, если он был отмечен как "грязный" (dirty). На место перезаписанного буфера читается требуемый блок.
Рис. 2.35. Организация работы с кэш-памятью
При выполнении функции обновления данных какого-либо файла сервера операционная система читает при необходимости требуемый блок в кэш-память (см. выше), выполняет операцию обновления и отмечает этот буфер как "грязный". Обновлённый буфер попадает на диск не сразу. Операционная система через определённый интервал времени запускает системный процесс, который анализирует кэш-память и перезаписывает "грязные" буфера на диск. Интервал времени, через который запускается системный процесс, регулируется с помощью двух SET-параметров (таблица 2.14).
Таблица 2.14. SET-параметры, регулирующие интервал перезаписи "грязных" буферов на диск
SET-параметр | Значение по умолчанию | Границы изменения | Примечания | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dirty Directory Cache Delay Time | 0,5 сек | 0 -10 сек | Определяет, через какой интервал времени перезаписываются на диск "грязные" буфера директорий, где хранятся записи таблиц DET. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
Dirty Disk Cache Delay Time | 3,3 сек | 0,1 - 10 сек | Определяет, через какой интервал времени перезаписываются на диск "грязные" буфера файлов. |
Упорядочивание и распараллеливание запросов поиска на дисках
В настоящее время наибольшее распространение получили два интерфейса связи контроллера с жёстким диском:
Интерфейс Enhanced IDE поддерживает два канала, к каждому из которых могут подключаться по два устройства (HARD-диски, CD-ROM и т. д.).
Более новым является интерфейс SCSI-2 (рисунок 2.36).
Для подключения какого-либо устройства по интерфейсу SCSI-2 в расширительный слот компьютера (в частности файлового сервера) устанавливается HOST-адаптер (HBA, DCB и т. д.). К HOST-адаптеру можно подключить до 7 контроллеров (два внутренних и пять внешних): HARD-диски, CD-ROM, CD-R, принтеры, сетевые адаптеры, сканеры, стриммеры. Обмен данными с подключёнными устройствами выполняется в режиме мультиплексирования (т. е. параллельного доступа).
Рис. 2.36. Схема подключения устройств по интерфейсу SCSI
Для HARD-дисков, подключённых по SCSI-интерфейсу, поддерживается восходящий поиск (интеллект шины) на аппаратном уровне (рисунок 2.37).
Рис. 2.37. Восходящий (лифтовый) поиск на диске
По запросу прикладной программы драйвер жёсткого диска рассчитывает номер цилиндра, номер поверхности и номер блока, где располагаются требуемые данные, и формирует команду, направляемую HOST-адаптеру.
Рабочие станции взаимодействуют с драйвером жёсткого диска файлового сервера по NCP-протоколу. Поэтому на HOST-адаптер может поступить несколько команд одновременно. В этом случае HOST-адаптер направляет эти команды контроллеру диска (рисунок 2.37). На рисунке цифрами обозначены номера цилиндров, указанных в командах поиска. Гребёнка головок чтения/записи начинает движение с нулевого цилиндра, и требуемые блоки читаются не в порядке их указания в командах, а в порядке их размещения на цилиндрах. Т. е. сначала будут считаны блоки, расположенные на 1-ом цилиндре, затем на 2-ом цилиндре и т. д. В этом случае гребёнка головок выступает в роли лифта, цилиндры - в роли этажей, блоки - в роли пассажиров.
Следует отметить, что использование этого метода чтения данных существенно повышает производительность дисковой системы. Действительно, если бы блоки читались в той последовательности, в которой они были указаны в командах, то для этого потребовалось бы 19 перемещений головок (для примера на рисунке 2.37). При использовании лифтового поиска для этого потребуется 6 перемещений.
При использовании интерфейса IDE операционная система NetWare выполняет программное моделирование восходящего поиска, который был рассмотрен выше.