|
ru.linux
- RU.LINUX ---------------------------------------------------------------------
From : Alex Tomas 2:5020/400 16 Dec 2002 13:11:18
To : Valentin Nechayev
Subject : Re: process stub. State: "Disk sleep" :(
--------------------------------------------------------------------------------
a>
From: Alex Tomas <bzzz@tmi.comex.ru>
>>>>> Valentin Nechayev (VN) writes:
VN> Hе морочьте голову. _Здесь_, на уровне подопечного драйверу
VN> железа и общения с ним, действительно VFS'у делать нечего, и Вы
VN> сами должны это отлично понимать (хотя почему-то юродствуете).
VN> Hа данном уровне драйвер должен уметь корректно сделать отработку
VN> запроса и отдать данные и статус завершения. Что он и делает (с
VN> поправкой на то, что в линуксовом SCSI ресет шины остается
VN> неизвестен работающим по соседним ID на той же шине и они сходят
VN> с ума - или уже это вылечили?) Уметь делать отмену запроса я
VN> пока что даже не прошу - это было бы значительно лучше для ряда
VN> действий того же VFS (типа правильно сделанного umount -f), но
VN> здесь я говорил не об этом.
правильные драйвера и железки надо пользовать.
см.. drivers/scsi/aic7xxx/aic7xxx_linux.c:ahc_linux_queue_recovery_cmd().
оно честно (сам видел не раз) пытается послать target reset. если target
совсем не отвечает (ни на attention, ни на select) - выставляет BUS RESET.
то есть на правильных железках все вполне даже нормально работает.
для неправильных железок оставлена возможность BUS RESET. зачастую
только это и помогает. и совсем тут linux не при чем.
VN> Делает. К чему Вы подчеркнули это "должен"? Опять плохо читаете?
VN> Повторяю: Вынули дискету. Драйвер честно говорит "чё? я не я,
VN> корова не моя" - то есть драйвер таки заметил, что выполнить
VN> операцию не удастся.
дабы не быть совсем голословным, покажите пожалуйста какой-нить
backtrace, дабы можно было однозначно решить: это драйвер или ошибка VFS
AT> здесь есть пока только два неприятных момента: 1) не все драйвера
AT> написаны правильно
VN> И не все драйвера устройств, и не драйвер FS, и не VFS.
в чем неправильность VFS?
AT> 2) completion пока возвращает только бинарный статус
AT> (success/fail)
VN> И это тоже.
это никак не мешает в данной ситуации. более того, на Kernel Summit
2.5 обсуждалась необходимость решения этой задачи. видимо пока руки
не дошли
VN> Вы меня хотели удивить? Hет, не удивили. Естественно, если под
VN> операцию была драйверу отдана некоторая память для буфера, то эта
VN> память не может быть освобождена от этой операции до тех пор,
VN> пока не будет точно известно, что операция завершилась или
VN> отменилась. Это факт, понятный каждому, кто внимательно прочел
VN> описание ядерных подсистем и подумал хотя бы минуту. Да, запрос
VN> на cancel может быть не выполнен и потому, что операция,
VN> например, уже состоялась. И что, это не может быть реализовано?
VN> Может. Просто надо было BIO layer не через %опу писать, как во
VN> всех юниксах до единого, а с учетом данных обстоятельств. По
VN> сравнению с тем, что, например, вытворяет сейчас Ingo Molnar, это
VN> будет студенческой поделкой ;)
зачем все это?
VN> Это у Вас совсем крышу повело, латать надо. С каких это пор
VN> read/write стали неотменяемыми? Они неотменяемы только для
VN> блочного I/O и только в пределах данного идиотского дизайна. Hа
VN> сокетах, пайпах, терминалах, параллельных портах, массе устройств
VN> - запросто отменяются, посылкой сигнала. И на дисках - было бы
VN> точно так же, если бы не глупость первичного дизайна.
это не глупость. это красивый способ избежать _ненужную_ сложность.
совершенно ненужную. или это так важно, до сигнал до процесса
добрался через 5 секунд, а не через 0.5 ? я с такой потребностью
не сталкивался, ты уж извини.
AT> таким образом, я рассматриваю твой пример совершенно
AT> недостаточным для переписывания VFS.
VN> А мне пофиг, что Вы там "рассматриваете". Верите? ;) Меня
VN> интересует тут одно: иметь такую VFS и такие нижележащие слои,
VN> чтобы система не умирала от оторванного, например, USB
VN> винчестера; или NFS сервера; чтобы можно было завершить процесс,
VN> задумавшийся на таком диске или сервере; чтобы работал umount -f
VN> и после этого система не стояла в позе зю. То есть чтобы на
VN> машине можно было *работать*, а не дрожать от того, что в любой
VN> момент она может умереть сама или попасть в позу, требующую
VN> перезагрузки.
еще раз. в два раза медленее: чем в данном случае плох VFS? в каком
"месте" он умирает и от чего?
я вот совсем не дрожу? Верите? ;)
NFS - это слишком особенно. Его нужно рассматривать отдельно.
AT> возможность управлять I/O на более тонком уровне заложена в AIO,
AT> который попал в 2.5 (правда пока лишь частично) и в котором
AT> _можно_ драйверу давать более тонкие указания. в том числе, io
AT> request cancel
VN> Дешёвый ржавый костыль, к тому же рекомендуемый Вами совершенно
VN> не по назначению.
вах!
снова вижу, что дядя пытается с больной головы переложить на здоровую.
1) D - это прекрасное дизайнерское решение, разделяющее функциональные
уровни и не позволяющее писакам драйверов делать свою работу как
попало. какая была шутка насчет "если бы дома строили так же ..." ?
так вот ты предлагаешь дома строить так, чтобы штукатурщики заботились
о фундаменте ...
2) где доказательство того, что в случае с выдергиванием дискетки лажает
VFS, а не драйвер? будь добр, приведи их. иначе не о чем говорить
3) _зачем_ городить принудительную отмену disk I/O, если время на одну
операцию сравнительно мало и при правильно написаном драйвере все
будет ok. советую так же отличать pipe/socket от disk'а. или от диска
уже можно ждать какой-то собственно активности как от сокета?
--
пора
--- ifmail v.2.15dev5
* Origin: HOME (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
