|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Tomas 2:5020/400 16 Dec 2002 02:09:17
To : Valentin Nechayev
Subject : Re: process stub. State: "Disk sleep" :(
--------------------------------------------------------------------------------
>>>>> Valentin Nechayev (VN) writes:
AT> приведи пример, когда для этого обязательно нужно править VFS и
AT> недостачно _правильно_ сделать драйвер.
VN> Что есть "_правильно_ сделать драйвер"? Дать ему возможность
VN> отказываться от операции по сигналу?
драйвер должен понимать, что случилась некая беда и он не может
обработать запрос (в том числе в заданный промежуток времени).
например, произошел submit_bh()/generic_make_request(), какой-то
запрос ушел в aic7xxx/sym53c8xx, дальше он попал на target, который
неожиданно сдох. в SCSI системе срабатывает timeout через N секунд,
драйвер пытаеца восстановить связь с target'ом (reselect + reset message,
если не получилось - BUS RESET и так далее), попробовал несколько
раз - не выходит. значит он дергает completion с uptodate=0, который
будит процесс стоящий в uninterruptible sleep на этом запросе.
зачем здесь VFS'у что-то делать?
AT> потом я тебе приведу пару примеров ...
VN> Вынули дискету. Драйвер честно говорит "чё? я не я, корова не
VN> моя" Система умирает с паникой. Вариант той же позы -
VN> смонтировать в r/w дискету с запретом записи (ползунок в углу
VN> дискеты). Hеоднократно замечалось на Linux и на FreeBSD (данных
VN> по другим не имею).
драйвер _должен_ понять, что media отсутствует и доложить об этом
VFS'у через buffer completion routine. здесь есть пока только два
неприятных момента:
1) не все драйвера написаны правильно
2) completion пока возвращает только бинарный статус (success/fail)
а теперь мой пример:
1) запрос ушел в sym53c8xx в виде sg-листа
2) на LSI чипе закрутился DSP, выполняя SPI и взаимодействуя с таргетом.
3) DSP свернуло крышу (там у них полно глюков, errata с десяткам пунктов)
4) твой VFS хочет cancel'ить запросу, но host не может связаться с DSP
что здесь делать? если ты его все же заканцелишь, то:
1) VFS вернет кому надо ошибку
2) через какое-то время DSP повторно ударится головой и оживет
3) в соответствии с полученным sg-листом он чего-то насует в память, которая
возможно уже отдана совсем другой подсистеме
конечно, можно и такие ситуации обрабатывать, но стоит-ли овчинка выделки?
тем более что VFS изначально ориентирована на _синхронные_ запросы (стандарнтые
read/write), которые не могут _отменить_ себя.
таким образом, я рассматриваю твой пример совершенно недостаточным для
переписывания VFS.
возможность управлять I/O на более тонком уровне заложена в AIO, который попал
в 2.5 (правда пока лишь частично) и в котором _можно_ драйверу давать более
тонкие указания. в том числе, io request cancel
--
пора
--- ifmail v.2.15dev5
* Origin: HOME (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
