Главная страница  Межпроцессное взаимодействие (состязание) 

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 [ 72 ] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

К сожалению, у данного алгоритма есть свои недостатки. Предположим, во время обработки запросов, показанных на рис. 3.13, поступили новые запросы. Например, после обработки обращения к цилиндру 16 приходит новый запрос к цилиндру 8. Этот запрос будет иметь приоритет над обращением к цилиндру 1. Затем, если поступит запрос к цилиндру 13, головка опять начнет перемещаться к цилиндру 13 для обработки нового запроса, а запрос к цилиндру 1 останется необработанным. При сильной загрузке диска головка диска будет большую часть времени находиться где-то в районе средних цилиндров, а запросам к крайним цилиндрам диска придется ждать, пока нагрузка диска случайно не снизится и обращений к середине диска не станет меньше. В результате качество обслуживания запросов к цилиндрам, удаленным от срединной части, может оказаться низким. То есть в конфликт вступают принцип минимизации времени отклика и принцип справедливости.

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

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

Рисунок 3.14 иллюстрирует работу элеваторного алгоритма с теми же семью запросами, что были использованы в качестве примера на рис. 3.13. Предполагается, что изначально бит направления движения указывал ВВЕРХ. При этом цилиндры обслуживаются в порядке 12, 16, 34, 36, 9 и 1, что соответствует перемещению блока головок на 1, 4, 18, 2, 27 и 8 цилиндров и в сумме составляет 60 цилиндров. В данном случае элеваторный алгоритм оказался даже слегка лучше, чем алгоритм SSF, однако на практике он обычно несколько хуже. Достоинство элеваторного алгоритма состоит в том, что при любом заданном наборе запросов верхняя граница необходимых перемещений блока головок для выполнения всех запросов фиксирована и офаничена удвоенным числом цилиндров.

Незначительная модификация этого алгоритма с меньшим разбросом времени отклика состоит в том, чтобы сканировать цилиндры всегда в одном направлении [82]. После обслуживания обращения к цилиндру с самым высоким номером блок головок перемещается к самому нижнему запрашиваемому цилиндру и далее продолжает движение вверх. Таким образом, самый нижний цилиндр как бы считается расположенным выше самого верхнего.



Начальная позиция

X XX

Последовательность перемещения головки

35 Цилиндр

Рис. 3.14. Элеваторный алгоритм планирования обращений к диску

Некоторые контроллеры дисков предоставляют программному обеспечению способ узнавать номер текущего сектора под головкой. Такие контроллеры позволяют использовать дополнительный метод оптимизации. Если есть два или более запросов к одному и тому же цилиндру, драйвер может выбрать из них тот, сектор которого пройдет под головкой первым. Обратите внимание, что при наличии нескольких головок у диска последовательные запросы могут обращаться к различным дорожкам на одном цилиндре. Контроллер может практически мгновенно переключаться с головки на головку, так как такое переключение не требует ни перемещения блока головок, ни ожидания поворота диска.

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

У современных жестких дисков производительность настолько зависима от задержек перемещения головок и вращения диска, что читать по одному или по два сектора крайне неэффективно. В силу чего многие современные контроллеры дисков читают и сохраняют в кэще по несколько секторов сразу, даже если запрашивается всего один сектор. Обычно при этом считывается запрашиваемый сектор и все остальные секторы дорожки, при условии что для них достаточно места в кэше контроллера. Например, у диска, описанного в табл. 3.5, размер кэша обычно составляет 2 Мбайт или 4 Мбайт. Режим использования кэша динамически определяется контроллером. В простейшем режиме кэш разделяется на две секции, одна для запросов чтения, другая для запросов записи. Если последующий запрос на чтение сектора может быть удовлетворен прямо из кэша контроллера, запрашиваемые данные могут быть выданы немедленно.

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



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

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

. Важно понимать, что во всех вышеизложенных алгоритмах планирования работы дисков молчаливо подразумевается, что физическая геометрия дисков совпадает с виртуальной. Иначе планирование обращений к диску не имеет никакого смысла, так как операционная система не сумеет определить, какой цилиндр расположен ближе к цилиндру: 39-й, 40-й или 200-й. С другой стороны, если контроллер диска способен принимать несколько внешних запросов одновременно, он в состоянии осуществлять все планирование внутри себя. В этом случае алгоритмы сохраняют силу, но выполняются на более низком уровне, в контроллере.

Обработка ошибок

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

1. Ошибки профаммирования (например, запрос несуществующего сектора).

2. Временная ошибка контрольной суммы (например, вызванная пылью, попавшей на головку).

3. Постоянная ошибка контрольной суммы (физическое повреждение блока).

4. Ошибка поиска (допустим, головка была отправлена на 6-й цилиндр, но оказалась на 7-м).

5. Ошибка контроллера (например, контроллер отказался принимать команду). Обрабатывать все эти ошибки наилучшим образом - задача драйвера диска. Ошибки программирования возникают, когда драйвер передает контроллеру

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



1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 [ 72 ] 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187

© 2000 - 2018 ULTRASONEX-AMFODENT.RU.
Копирование материалов разрешено исключительно при условии цититирования.