|
ru.unix
- RU.UNIX ----------------------------------------------------------------------
From : Valentin Nechayev 2:5020/400 21 Aug 2002 10:16:20
To : Vasily Korytov
Subject : Re: зависший процесс
--------------------------------------------------------------------------------
>>> Vasily Korytov wrote:
VN>> Hепрерываемость дискового и NFS'ного sleep - одна из грубейших ошибок
VN>> проектирования unix'ов.
VK> Пожалуйста, расскажи, почему ты так считаешь. Для меня это неочевидно.
Тут скорее даже не непрерываемость, а ее причина - идиотское построение
работы с драйверами. Hе предусмотрены: 1) асинхронная отработка запроса
(хотя в канонической староюниксовой архитектуре против нее нет никаких
возражений - и IPL'и можно ставить как угодно, и completion вызвать,
и wakeup дернуть, и никто тебе не сделает schedule в самый ответственный
момент, и запускать kernel-only процессы для устойчивой обработки на уровне
softinterrupt никто не мешает); 2) отмена запроса к драйверу. При том,
что все это уже было давно - вспомнить хотя бы RT-11, RSX-11 и иже с ними.
В книге по Инмос есть забавное замечание - мол, архитектурный запрет
переключения процессов, находящихся в системной фазе, - решение действенное,
но слишком грубое (например, не дает жить нормальному realtime). Оно показывает,
что более тонкие решения давно уже существовали и были неплохо известны.
В то же время в первых юниксах - был полный бардак. Сделать ожидание ввода
по времени - нереально. O_NONBLOCK во всех видах - отсутствует, select -
отсутствует, AIO - отсутствует, сигналом можно только срубить процесс и ничего
более (обработчики неустойчивы, какое-то улучшение наступило только когда
BSD и ATT параллельно друг другу начали делать reliable signals - а это не
только sigprocmask и sigaction, а и вообще изменение метода реакции ядра
на сигналы, включая sleep и sysentry). Даже подождать пару минут ввода
с консоли и потом сказать "оп-па, ваше время истекло" было нереально.
Когда вводили неблокирующий режим и прерывание сигналом, его ввели для
тех операций, которые заведомо могли иметь неограниченный по длительности
характер - тот же read с терминала или из пайпа. Hо для диска было решено,
что ну его нафиг, bio layer менять - себе дороже, и лучше мы в star trek
поиграем.
А потом пришел NFS. Который и BIO, и в то же время сетевой. А системы
устойчивостью не отличаются - они и сейчас не слишком устойчивы, а тогда -
тем более. А потом все чаще стало оказываться, что надо сохранять жизнь
запущенной системы несмотря на местные сбои, и оказалось, что VFS совершенно
не понимает невозможность работы с диском (позы с panic при записи на
защищенную от записи дискету многие помнят), umount насильный невозможен -
хотя почти вся работа там подставить на все vnode фиктивные VMT и
отцепить буфера запрошенных операций - ан нет, базовая идея что с
диском проблем у нас не бывает и что BIO всегда выполняет свои действия
точно и в срок - проникла всюду. Что и дает нынешнее убогое состояние.
Ты сейчас просто не представляешь себе, каким дерьмом был unix раньше
и как его из этого состояния вытаскивали за уши. В первых sh даже cd был
внешней программой - сейчас кому-то сказать, кто знает про сисколл chdir(),
но не знает истории, даст приступ истерического смеха. Эта команда лезла
в память своего родителя и там меняла текущий каталог. А для этого ей
еще надо было загрузиться с диска (кэша никакого кроме как на 15 блоков
включая суперблоки - не было...)
То, что сейчас видим - результат того, что народ взял то, что было доступно -
эту совершенно непригодную для промышленной работы систему - и начал ее
доводить, потому что это было дешевле, чем писать с нуля или покупать
серьезные системы. А в результате имеем то что имеем - под слоем новой
красивой краски выглядывают слои плохо замазанной ржавчины...
/netch
--- ifmail v.2.15dev5
* Origin: Dark side of coredump (2:5020/400)
Вернуться к списку тем, сортированных по: возрастание даты уменьшение даты тема автор
|
