|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 16 Dec 2002 11:44:48
To : Alex Tomas
Subject : Re: process stub. State: "Disk sleep" :(
--------------------------------------------------------------------------------
>>> Alex Tomas wrote:
AT> драйвер должен понимать, что случилась некая беда и он не может
AT> обработать запрос (в том числе в заданный промежуток времени).
AT> например, произошел submit_bh()/generic_make_request(), какой-то
AT> запрос ушел в aic7xxx/sym53c8xx, дальше он попал на target, который
AT> неожиданно сдох. в SCSI системе срабатывает timeout через N секунд,
AT> драйвер пытаеца восстановить связь с target'ом (reselect + reset message,
AT> если не получилось - BUS RESET и так далее), попробовал несколько
AT> раз - не выходит. значит он дергает completion с uptodate=0, который
AT> будит процесс стоящий в uninterruptible sleep на этом запросе.
AT> зачем здесь VFS'у что-то делать?
Hе морочьте голову. _Здесь_, на уровне подопечного драйверу железа и общения
с ним, действительно VFS'у делать нечего, и Вы сами должны это отлично
понимать (хотя почему-то юродствуете).
Hа данном уровне драйвер должен уметь корректно сделать отработку запроса
и отдать данные и статус завершения. Что он и делает (с поправкой на то, что
в линуксовом SCSI ресет шины остается неизвестен работающим по соседним ID
на той же шине и они сходят с ума - или уже это вылечили?)
Уметь делать отмену запроса я пока что даже не прошу - это было бы значительно
лучше для ряда действий того же VFS (типа правильно сделанного umount -f),
но здесь я говорил не об этом.
AT>> потом я тебе приведу пару примеров ...
VN>> Вынули дискету. Драйвер честно говорит "чё? я не я, корова не
VN>> моя" Система умирает с паникой. Вариант той же позы -
VN>> смонтировать в r/w дискету с запретом записи (ползунок в углу
VN>> дискеты). Hеоднократно замечалось на Linux и на FreeBSD (данных
VN>> по другим не имею).
AT> драйвер _должен_ понять, что media отсутствует и доложить об этом
AT> VFS'у через buffer completion routine.
Делает. К чему Вы подчеркнули это "должен"? Опять плохо читаете?
Повторяю:
VN>> Вынули дискету. Драйвер честно говорит "чё? я не я, корова не
VN>> моя"
- то есть драйвер таки заметил, что выполнить операцию не удастся.
AT> здесь есть пока только два
AT> неприятных момента:
AT> 1) не все драйвера написаны правильно
И не все драйвера устройств, и не драйвер FS, и не VFS.
AT> 2) completion пока возвращает только бинарный статус (success/fail)
И это тоже.
AT> а теперь мой пример:
AT> 1) запрос ушел в sym53c8xx в виде sg-листа
AT> 2) на LSI чипе закрутился DSP, выполняя SPI и взаимодействуя с таргетом.
AT> 3) DSP свернуло крышу (там у них полно глюков, errata с десяткам пунктов)
AT> 4) твой VFS хочет cancel'ить запросу, но host не может связаться с DSP
AT> что здесь делать? если ты его все же заканцелишь, то:
AT> 1) VFS вернет кому надо ошибку
AT> 2) через какое-то время DSP повторно ударится головой и оживет
AT> 3) в соответствии с полученным sg-листом он чего-то насует в память, которая
AT> возможно уже отдана совсем другой подсистеме
Вы меня хотели удивить? Hет, не удивили.
Естественно, если под операцию была драйверу отдана некоторая память для буфера,
то эта память не может быть освобождена от этой операции до тех пор, пока
не будет точно известно, что операция завершилась или отменилась.
Это факт, понятный каждому, кто внимательно прочел описание ядерных подсистем
и подумал хотя бы минуту.
Да, запрос на cancel может быть не выполнен и потому, что операция, например,
уже состоялась. И что, это не может быть реализовано? Может.
Просто надо было BIO layer не через %опу писать, как во всех юниксах до единого,
а с учетом данных обстоятельств. По сравнению с тем, что, например, вытворяет
сейчас Ingo Molnar, это будет студенческой поделкой ;)
AT> конечно, можно и такие ситуации обрабатывать, но стоит-ли овчинка выделки?
AT> тем более что VFS изначально ориентирована на _синхронные_ запросы
AT> (стандарнтые read/write), которые не могут _отменить_ себя.
Это у Вас совсем крышу повело, латать надо. С каких это пор read/write
стали неотменяемыми? Они неотменяемы только для блочного I/O и только
в пределах данного идиотского дизайна. Hа сокетах, пайпах, терминалах,
параллельных портах, массе устройств - запросто отменяются, посылкой сигнала.
И на дисках - было бы точно так же, если бы не глупость первичного дизайна.
AT> таким образом, я рассматриваю твой пример совершенно недостаточным для
AT> переписывания VFS.
А мне пофиг, что Вы там "рассматриваете". Верите? ;)
Меня интересует тут одно: иметь такую VFS и такие нижележащие слои,
чтобы система не умирала от оторванного, например, USB винчестера;
или NFS сервера; чтобы можно было завершить процесс, задумавшийся на таком
диске или сервере; чтобы работал umount -f и после этого система не стояла
в позе зю. То есть чтобы на машине можно было *работать*, а не дрожать
от того, что в любой момент она может умереть сама или попасть в позу,
требующую перезагрузки.
AT> возможность управлять I/O на более тонком уровне заложена в AIO, который
AT> попал в 2.5 (правда пока лишь частично) и в котором _можно_ драйверу давать
AT> более тонкие указания. в том числе, io request cancel
Дешёвый ржавый костыль, к тому же рекомендуемый Вами совершенно не по
назначению.
-netch-
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
