Ключевые слова:security, scsi, (найти похожие документы)
_ RU.LINUX (2:5077/15.22) ___________________________________________ RU.LINUX _
From : Alex Korchmar 2:5020/28.100 17 Nov 98 01:43:14
Subj : кстати, о багах (scsi)
________________________________________________________________________________
Hi All,
хотите багов? их есть.
Лабораторная работа номер 1. Линуксовый scsi - сплошной неразлепляемый баг.
Приборы и материалы: линукс - одна штука (лучше всего - последнее девелоперское
ядро, чтоб уж никаких сомнений), scsi-система - одна штука, винт на этой скази -
одна или более штуков, тормозное scsi-устройство, не умеющее disconnect - одна
штука.
В моем случае это оказался древний scsi-1 стриммер.
Теоретическая часть.
Как известно, линуксовая сказя - самая замечательная в мире сказя. Ибо у нее
есть всего два таймаута - маленький и немаленький. Выбирающиеся в ядре,
непосредственно mid-level кодом scsi, на основании партийного чутья (т.е. на
самом деле на основании анализа команды. Да, да - не делайте круглых глаз. Этот
код _сам_ парсит пропихиваемые через него команды, и, помимо прочего, решает,
маленький или немаленький таймаут ей положен. Обычно положен маленький.) Если за
отведенное время команда не выполнилась, не делается никаких попыток
поинтересоваться причиной, а делается попытка scb abort. Если она не удалась -
ресет устроства - target этой команды. Если она не удалась - reset scsi-хоста
целиком.
Практическая часть. [предполагается, что практиканты прослушали краткий "курс
техники безопасности при работе с кривыми юниксами" и знают, что такое бэкап. За
пострадавшие винчестеры я отвественности не несу]
tar -cvf /dev/st0 что-нибудь-большое. Hам важно, чтобы лента умоталась
достаточно далеко.
А теперь - сюрприз, сюрприз: mt -f /dev/nst0 rewind (mt всегда ожидает
завершения команды)
Предположим, что ленте крутиться в исходную точку чуть больше, чем "маленький
таймаут". Предположим, что /sbin/update, как обычно, дергает диск. Вам
предлагается полюбоваться, что при этом происходит.
Аналитическая часть.
Пусть стриммер при ресете прекращает операцию, как и положено приличному, пусть
и слегка устаревшему устройству.
Рассчитайте, сколько раз сресетится ваш хост-адаптер, прежде, чем ленту удастся
вытащить, если время перемотки ленты вчетверо превышает "маленький" таймаут, а
заодно - какова вероятность ресета в момент выполнения винчестером все же
добравшегося до него write и среднеквадратичное отклонение содержимого
произвольного сектора от того, что на самом деле должно было там оказаться.
Hапоминаю, что в теоретической части указывалось - в первую очередь ресетится ни
в чем не повинный винчестер, поскольку именно ему адресована злополучная
команда, застрявшая в очереди на обработку из-за того, что шину держит стриммер.
Вопросы к зачету:
1. почему хреново совмещать на одной шине быстрые и медленные scsi-устройства
2. почему я не буду писать все это в linux-scsi [нет, я не возражаю, если кто-то
это там перескажет]
> Alex
--- MadMED v0.42i/DOS (Nov 27 1997 18:40:55) * Origin: Down System (2:5020/28.100)
