Буферизация при блок-ориентированном обмене

Одним из достоинств ОС Unix является организация многоуровневой буферизации при выполнении неэффективных действий[R40] . В частности, для организации блок-ориентированных обменов система использует стандартную стратегию кэширования. Все действия тут те же самые (вплоть до отдельных нюансов). Цель кэширования — минимизация обменов с внешними устройствами.

Для буферизации используют пул буферов, размером в один блок каждый. Вкратце рассмотрим алгоритм, состоящий из пяти действий.

1. Поиск заданного блока в буферном пуле. Если удачно, то переход на п.4

2. Поиск буфера в буферном пуле для чтения и размещения заданного блока.

3. Чтение блока в найденный буфер.

4. Изменение счетчика времени во всех буферах.

5. Содержимое данного буфера передается в качестве результата.

Итак, повторимся: ОС Unix была одной из первых массово распространенных операционных систем, использующих кэширование дисковых обменов. Соответственно, за счет минимизации реальных обращений к физическим устройствам работа системы более эффективная. Но эта организация системы имеет и свои очевидные недостатки. Во-первых, кэширование дисковых обменов приводит к тому, что имеется несоответствие реального содержимого диска и того содержимого, которое должно быть на нем. Соответственно, при сбое системы возможна потеря информации в КЭШах, располагаемых в оперативной памяти. В частности, при сбое возможна потеря индексного дескриптора. Конечно, во время работы система сбрасывает актуальную информацию по местам дислокации, но этого недостаточно. Если теряется индексный дескриптор, то теряется список блоков файла. За счет использования избыточной информации можно организовать и восстановление. Но заметим, что при сбое теряется лишь файл, работоспособность системы остается.

Альтернативными являются системы, работающие без буферизации, когда при каждом обмене происходит реальное обращение к физическому устройству. Эти системы более устойчивы к сбоям в аппаратуре. Примером такой системы может служить Microsoft DOS. Соответственно, при развертывании на ненадежной аппаратуре операционной системы Unix многие ее положительные качества могли теряться.

Борьба со сбоями

Так или иначе, но в ОС Unix есть ряд традиционных средств для минимизации ущерба при отказах. Во-первых, в системе может быть задан параметр, определяющий промежутки времени, через которые осуществляется сброс системных данных по местам дислокации.

Во-вторых, в системе доступна команда sync, позволяющая осуществлять в любой момент этот сброс информации по желанию пользователя.

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

[1] Для создания файла FIFO в UNIX System V.3 и ранее используется системный вызов mknod(), а в BSD UNIX и System V.4 — вызов mkfifo() (этот вызов поддерживается и стандартом POSIX).

[2] В данном случае это решение не совсем корректно, поскольку делается предположение, что процессы A и B за 10 единиц времени должны получить последние сообщения. Но для простоты решения мы опускаем проблемы синхронизации.

[3] В этом случае возможна некорректная работа, если процессы A и/или B запускаются раньше основного процесса. В этом случае они обратятся к пока еще не созданному ресурсу, что приведет к ошибке.

[R1]Лекция 1.

[R2]Лекция 2.

[R3]Лекции 3 и 4.

[R4]

НЕПОНЯТНО сказано.

[R5]Схему необходимо подправить, поскольку, например, данные от ВЗУ передаются на ОЗУ через шину под управлением моста, а не ЦП.

[R6]Лекция 5.

[R7]Лекция 6.

[R8]Лекция 7.

[R9]Лекция 8.

[R10]Лекции 9 и 10.

[R11]Почему нет рисунка для этого типа?

[R12]Лекция 11.

[R13]Лекции 23 и 24, прочитанные Терехиным А.Н.

[R14]Лекция 12.

[R15]Про это ничего не сказано!!!

[R16]Лекция 13.

[R17]Лекция 14.

[R18]Лекция 14.

[R19]В лекции про это явно не рассказывалось, но я решил на всякий случай включить этот материал в конспект.

[R20]Зачем идет обращение к сегменту кода, когда уже известен номер регистра???

[R21]Конец лекции 14 — начало лекции 15.

[R22]Взято из заметок к старым слайдам. На лекции про это НЕ ГОВОРИЛИ.

[R23]Взято из заметок к старым слайдам. На лекции про это НЕ ГОВОРИЛИ.

[R24]Лекция 16.

[R25]Взято из заметок к старым слайдам. На лекции про это НЕ ГОВОРИЛИ.

[R26]На лекции были еще слайды со схемами работы с сокетами с (без) установлением соединения. Они повторяют вышесказанное, поэтому я их опустил и тут не привожу.

[R27]Лекция 17.

[R28]Лекция 18.

[R29]Ничего не сказано про случай, когда один и тот же блок встречается и в таблице свободных, и в таблице занятых блоков ФС!?

[R30]Лекция 18.

[R31]Лекция 19.

[R32]Лекция 20 от 24.11.05.

[R33]

УТОЧНИТЬ РАЗМЕР! На лекции лектор забыл точный размер.

[R34]

Продолжение лекции 20 см. Раздел 6.

[R35]Лекция 22 от 01.12.05.

[R36]Лекция 20 (продолжение).

[R37]Лекция 21 от 01.12.05.

[R38]Удалил ?strategy(),т.к. ничего не говорилось по ней.

[R39]Это определения взято из Робачевского.

[R40]В устной лекции был отвлеченный пример:

«Например, если пользователь в командной строке вводит команду, не являющуюся командой интерпретатора, то последний начинает поиск в системе исполняемого файла с указанным именем. Если такой поиск будет выполняться каждый раз, то говорить об эффективности системы просто не придется. Единственный путь, оптимизирующий эту ситуацию, — ограничение области поиска. Это можно сделать за счет того, что каждому пользователю можно поставить в соответствие перечень каталогов, в которых можно искать команды, причем эти каталоги могут быть отсортированы по приоритетам».

И т.д. я его решил опустить здесь.

Как остановить буферизацию на YouTube


Похожие статьи.

Понравилась статья? Поделиться с друзьями: