ітність, Проводити відмінність между блокового І символьних прилаштувати, ТОМУ ЩО ВСТУП-Виведення для блокового прістроїв буферізуется в буферному кеші файлової системи. На рис. 3 наводитися Огляд різніх сценаріїв Відновлення на Рівні програми.
При фатального збої блокового драйвера Можливо повне Відновлення без ВТРАТИ даніх, прозоре для програми. Колі розпізнається збій, сервер реінкарнації запускає нову копію драйвера и скідає кеш файлової системи для сінхронізації. Таким чином, буферні кеш НЕ Тільки підвіщує Продуктивність, альо такоже є ВАЖЛИВО І для надійності.
Прозорі Відновлення іноді є можливіть и при збоях драйверів символьних прістроїв. Оскількі запит вводу-виводу НЕ буферізуется в кеші блоків файлової системи, інформація про помилки вводу-виводу винна буті доведена до програми. Если программа НЕ может прізвесті Відновлення, про проблему буде сповіщеній користувач. Фактично, збої драйверів проштовхуються на гору, что виробляти до різніх сценаріїв Відновлення. Наприклад, ЯКЩО відбувається збій драйвера Ethernet, то мережевий сервер помітіть відсутність пакетів и зробім прозоре Відновлення, ЯКЩО додаток вікорістовує надійний транспортний протокол, такий як TCP. З Іншого боку, ЯКЩО відбувається збій драйвера принтера, то користувач, Звичайний, помітіть, что его Виведення на друк Не вдаючись и повторити команду друку.
Таким чином, у багатьох випадка наша система может Забезпечити повне Відновлення на прикладного Рівні. У решті випадка інформація про збої ВСТУП-Виведення доводитися до користувача. Можна Було б пом'якшити Цю незручність Шляхом Використання тіньового драйвера для Відновлення Додатків, Який вікорістовувалі зіпсованій драйвер в момент его фатального збою, застосовуючі методи, продемонстровані в [25]. Нам не Дає сделать це шлюб робочої сіли. p> Результати перевіркі надійності
Для перевіркі надійності своєї системи ми вручну внесли збої в деякі з своих драйверів, щоб протестуваті деякі види помилок и посмотреть на ті, что Вийди. У найпростішому випадка ми завершувалі драйвер з! застосування сигналом SIGKILL. Більш серйозні Тестові випадка змушувалі драйвером разіменовівать погані покажчики або впадаті в нескінченній цикл. У всех випадка сервер реінкарнації розпізнавав проблему и заміняв несправностей драйвер свіжої копією.
Зх тестуванні надійності, мі вітяглі кілька уроків, ВАЖЛИВО для розробки Нашої системи. По-перше, оскількі сервер реінкарнації перезапускає несправні сервери І драйверами, нужно, щоб у них не зберігалося стан, І смороду могли б буті належноє чином повторно ініціалізувалі при повторному запуску. Компоненти, что зберігають стан, Такі як файлової системи и сервер процесів, Неможливо вілікуваті таким чином, оскількі смороду Дуже багато втрачають при перезапуску. Наші возможности обмежені. p> Інше спостереження Полягає в тому, что деякі драйвером були реалізовані таким чином, что ініціалізація відбувається Тільки при первом виклику OPEN. Однак для Прозоров Відновлення после збою драйвера на Рівні Додатків не винних турбувати Повторну виклик OPEN. Замість цього, Виконання виклику READ або WRITE у відновленому драйвері має змусіті драйвер прізвесті Повторну ініціалізацію.
Крім того, хочай ми візнаємо наявність перелогових между файлової системи І драйверами, Наші тести виявило деякі Другие взаємозалежності. Наприклад, наш інформаційний сервер, что відає на екран налагодження дампи при натісканні функціональніх клавіш, втрачає свое відображення клавіш после перезапуску. У якості Загальне правила, залежності слід запобігаті, и ВСІ компоненти повінні буті підготовлені для Боротьба з непередбачуванімі збоямі.
Нарешті, щоб ще больше підвіщіті Надійність, слід Изменить и корістувальніцькі Додатки. За історічнімі причинами в більшості програм передбачається, что будь-який збій драйвера є фатальним, и смороду негайно Здаються, хочай іноді Можливо Відновлення. Прикладом, в якому можливе Відновлення на Рівні програми, є печатка. Если демон лінійного принтера сповіщається про ТИМЧАСОВЕ збій драйвера, ВІН может автоматично повторно Видати команду друку без втручання користувача. Подальші ЕКСПЕРИМЕНТ з ПОНОВЛЕНИЙ на Рівні Додатків є Частинами Нашої майбутньої роботи.
7. Вімірювання продуктівності
Продуктивність є проблемою, супутньої мінімальнім ядер ПРОТЯГ десятіліть. Тому негайно постає питання: у что обходяться что обговорюваліся Вище Зміни? Щоб розібратіся в цьом, мі создали прототип, что Складається з невеликого ядра и підтрімуваного їм набору драйверів прістроїв и серверів, что Працюють в режімі користувача. У якості основи прототипу ми начали з Використання системи MINIX 2 з-за ее невеликого розміру и довгої истории. Код системи вівчався багатьма десятками тисяч студентов в сотнях УНІВЕРСИТЕТІВ ПРОТЯГ 18 років, и в Останні 10 років почти НЕ надход ПОВІДОМЛЕННЯ про помилки, что мают відношення до ядра; мабуть, відсутність помилок пов'язано з малімі розмі...
