 |
|
|
ru.linux- RU.LINUX --------------------------------------------------------------------- From : Valentin Nechayev 2:5020/400 15 Jul 2002 13:28:56 To : Alex Tomas Subject : Re: Slackware vs RH vs Mandrake etc. -------------------------------------------------------------------------------- >>> Alex Tomas wrote: VN>> А от отпадания одного драйвера - вполне можно защититься. Если VN>> VFS + VM построены разумно (чего нет в большинстве free unix) - VN>> даже если это был драйвер FS или диска. AT> хорошо.. если это драйвер fs, то что делать с активными структурами, AT> относящимися к процессам? Что есть активные структуры? О каком уровне речь? Посмотрите реализации 'umount -f' в linux и, например, freebsd5 (кажется, там она значительно мощнее чем в 4). Грубо говоря: проходим по списку vnodes, отрываем у тех, у которых эта FS, соответствующие рычаги, ставим вместо них какие-то dummy ones, затем отрываем собственно FS. Активные операции стараемся оборвать (как о позволенности этого я и говорил про разумность построения VFS и VM, хотя на самом деле надо начинать с исправления дебильной юниксовой схемы драйверов без возможности сделать abort запрошенной ранее операции, на любой стадии оной). Проблемы синхронизации - те же, что при любом MP доступе, и они уже решены. Или не решены, но обойдены (big kernel lock), что тоже достаточно для наших целей. AT> пытаться по ним восстановить состояние до AT> падения? гомморой. допустим это драйвер диска. что делать? пытаться AT> быстро загрузить драйвер снова? часть запросов останется необслуженными. AT> как быть с ними? считать их a-la bad blocks? или считать таковым весь AT> диск? единственное разумное применение вижу - software raid, но в AT> production он не так часто встречается. Hа самом деле, наиболее яркий пример разумного применения - NFS (network failure system, по Бернштейну;)) Костыль в виде soft mount - показатель того, что проблема остра и должна решаться. А все перечисленные Вами вопросы имеют практически однозначный ответ. Hет, никакой быстрой повторной загрузки средствами ядра не должно быть, по крайней мере в начальной реализации - как минимум диску надо сделать качественный fsck, и пусть админ или специальный демон думают об этом. Да, явные read/write должны завершиться с EIO. Да, объекты файлов должны перейти в состояние "я не я, и корова не моя" - EIO на все операции кроме close (ну и fcntl, понятное дело). Да, доступ по mmap к этим данным должен вызвать SIGSEGV и скорее всего смерть процессов, которые мапили оттуда данные, и однозначно смерть тех, кто мапил код - а что, были другие альтернативы? То есть, они, может, и есть, но для начала надо сделать это, а потом может оказаться, что кластерами - дешевле. AT> наверное еще имеет смысл для networks devices, но, опять же, редкая AT> ситуация, imho. Где как. Для NFS - достаточно частая, чтобы думать о том, чтобы не терять состояние и данные на ровном месте. AT> ибо обычно network driver - тупой и простой. довести AT> его до ума не так уж и сложно (я не принимаю во внимание стек, что AT> над ним) Увы, чем дальше тем более сложные драйвера требуются устройствам. А тем более если драйвер поставляется левым вендором. VN>> P.P.S. Кстати, сделать так, чтобы можно было часть драйверов по VN>> вкусу админа выносить в отдельные vm - достаточно несложно, а VN>> пользы было бы весьма и весьма. AT> не уверен. надо для этого драйвера создать as, которая будет содержать AT> _нужную часть_ общего kvm. опять же, надо будет аллоцировать память AT> под вновьприбывший, предположим, пакет. так как вы хотите максимально AT> изолировать драйвер от всего остального, придется обратно идти в общий AT> kvm, аллоцировать память, мапить ее оба as, идти снова в as драйвера. AT> не знаю, не знаю ... А зачем зацикливаться именно на решении через kvm? Пусть умеет и message passing. /netch --- ifmail v.2.15dev5 * Origin: Dark side of coredump (2:5020/400) Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
Архивное /ru.linux/11645df7e8668.html, оценка из 5, голосов 10
|
|
|