прозорі розподілені файлові системи

Зміст

Лекція №1. Вступ

Лекція №2. Периферійні процесори

Лекція №3. Зв’язок типу Newcastle

Лекція №4. „Прозорі” розподілені файлові системи

Лекція №5. Розподілена модель без передатних процесів

Лекція №6. Безпека в розподілених системах: середовищі баз даних

Лекція №7. Захищені СУБД інших постачальників

Висновки

Вправи

РОЗПОДІЛЕНІ СИСТЕМИ

Часто буває бажано з метою забезпечення спільного використання ресурсів розподіляти процесори таким чином, щоб вони були автономні від операційного середовища й умов експлуатації. Нехай, наприклад, користувачеві персональної ЕОМ потрібно звернутися до файлів, що перебувають на більшій машині, але зберегти при цьому контроль над персональною ЕОМ. Незважаючи на те, що окремі програми, такі як uucp, підтримують передачу файлів по мережі й інші мережні функції, їхнє використання не буде приховано від користувача, оскільки користувач знає про те, що він працює в мережі. Крім того, треба помітити, що програми, подібні до текстових редакторів, з віддаленими файлами, як з звичайними, не працюють. Користувачі повинні мати у своєму розпорядженні стандартний набір функцій системи UNIX й, за винятком можливої втрати у швидкодії, не повинні відчувати перетинання машинних границь. Так, наприклад, робота системних функцій open й read з файлами на віддалених машинах не повинна відрізнятися від їхньої роботи з файлами, що належать локальним системам. Архітектура розподіленої системи представлена на малюнку 1.1. Кожен комп'ютер, показаний на малюнку, є автономним модулем, що складається з ЦП, пам'яті й периферійних пристроїв. Відповідність моделі не порушується навіть незважаючи на те, що комп'ютер не має у своєму розпорядженні локальну файлову систему: він повинен мати периферійні пристрої для зв'язку з іншими машинами, а всі приналежні йому файли можуть розташовуватися й на іншому комп'ютері. Фізична пам'ять, доступна кожній машині, не залежить від процесів, виконуваних на інших машинах. Цією особливістю розподілені системи відрізняються від сильнозв’язаних багатопроцесорних систем. Відповідно, і ядро+-----------------------------+ +-----------------------------+| +------------+ | | +------------+ || | Процесори | | | | Процесори | || +-----+------+ | | +-----+------+ || ----+-------+------+------- | | ----+-------+------+------- || +---+----+ +-------+------+ | | +---+----+ +-------+------+ || | Пам’ять| | Периферійні | | | | Память | | Периферійні | || | | | пристрої | | | | | | пристрої | || +--------+ +--------------+ +-++-+ +--------+ +--------------+ |+-----------------------------+ ++ +-----------------------------+ | +-------------+---------------+ | +------------+ | | | Процесори | | | +-----+------+ | | ----+-------+------+------- | | +---+----+ +-------+------+ | | | Пам’ять| | Периферійні | | | | | | пристрої | | | +--------+ +--------------+ | +-----------------------------+ Малюнок 1.1. Модель системи з розподіленою архітектуроюсистеми на кожній машині функціонує незалежно від зовнішніх умов експлуатації розподіленого середовища. Розподілені системи традиційно діляться на наступні категорії: * периферійні системи, що представляють собою групи машин, що відрізняються яскраво вираженою спільністю й пов'язаних з однією (за звичай більшою) машиною. Периферійні процесори ділять своє навантаження із центральним процесором і переадресовують йому всі звертання до операційної системи. Ціль периферійної системи полягає в збільшенні загальної продуктивності мережі і в наданні можливості виділення процесора одному процесу в операційному середовищі UNIX. Система запускається як окремий модуль; на відміну від інших модулів розподілених систем, периферійні системи не мають реальної автономії, за винятком випадків, пов'язаних з диспетчеризацією процесів і розподілом локальної пам'яті. * розподілені системи типу "Newcastle", що дозволяють здійснювати дистанційний зв'язок по іменах віддалених файлів у бібліотеці (назва взята зі статті "The Newcastle Connection" - див. [Brownbridge 82]). Віддалені файли мають специфікацію (складене ім'я), що у вказівці шляху пошуку містить спеціальні символи або додатковий компонент імені, що йде поперед кореня файлової системи. Реалізація цього методу не передбачає внесення змін у ядро системи, внаслідок цього він більш простий, чим інші методи, що тут розглянуті, але менш гнучкий. * абсолютно "прозорі" розподілені системи, у яких для звертання до файлів, розташованих на інших машинах, досить вказівки їх стандартних складових імен; розпізнавання цих файлів як віддалених входить вобов'язок ядра. Маршрути пошуку файлів, зазначені в їхніх складових іменах, перетинають машинні границі в точках монтування, скільки б таких точок не було сформовано при монтуванні файлових систем на дисках. У подальшому ми розглянемо архітектуру кожної моделі; усі наведені відомості базуються не на результатах конкретних розробок, а на інформації, що публікувалася в різних технічних статтях. При цьому припускається, що турбота про адресацію, маршрутизацію, керування потоками, й виправленні помилок покладає на модулі протоколів і драйверів пристроїв, інакше кажучи, що кожна модель не залежить від використовуваної мережі. Приклади використання системних функцій, що приводять у наступному розділі для периферійних систем, працюють аналогічним способом і для систем типу Newcastle і для абсолютно "прозорих" систем, про які піде мова пізніше; тому в деталях ми їх розглянемо один раз, а в розділах, присвячених другим типам систем, зупинимося в основному на особливостях, що відрізняють ці моделі від всіх інших.

ПЕРИФЕРІЙНІ ПРОЦЕСОРИ

Архітектура периферійної системи показана на малюнку 1.2. Мета такої конфігурації полягає в підвищенні загальної продуктивності мережі за рахунок перерозподілу виконуваних процесів між центральним і периферійними процесорами. У кожного з периферійних процесорів немає в розпорядженні інших локальних периферійних пристроїв, крім тих, які йому потрібні для зв'язку з центральним процесором. Файлова система й всі пристрої перебувають у розпорядженні центрального процесора. Припустимо, що всі користувальницькі процеси, що виконуються на периферійному процесорі і між периферійними процесорами, не переміщаються; будучи один раз передані процесору, вони перебуваютьна ньому до моменту завершення. Периферійний процесор містить полегшений варіант операційної системи, призначений для обробки локальних звернень до системи, керування перериваннями, розподілу пам'яті, роботи з мережевими протоколами й із драйвером пристрою зв'язку з центральним процесором. При ініціалізації системи на центральному процесорі ядро по лініях зв'язку завантажує на кожному з периферійних процесорів локальну операційну систему. Любий виконуваний на периферії процес пов'язаний із процесом-супутником, що належить центральному процесору (див. [Birrell 84]); коли процес перетікає на периферійному процесорі, викликає системну функцію, що має потребу в послугах винятково центрального процесора, периферійний процес зв'язується зі своїм супутником і запит надходить на обробку на центральний процесор. Процес-супутник виконує системну функцію й посилає результати назад на периферійний процесор. Взаємини периферійногопроцесу зі своїм супутником схожі на відносини клієнта й сервера, докладно розглянуті нами далі: периферійний процес виступає клієнтом свого супутника, що підтримує функції роботи з файловою системою. При цьомувіддалений процес-сервер має тільки одного клієнта. У наступних розділах ми роздивимося процеси-сервери, що мають клієнтів. Коли периферійний процес викликає системну функцію, яку можна проробити локально, ядру немає потреби надсилати запит процесу-супутникові.Для того, щоб пояснити, яким чином працює периферійна система,розглянемо ряд функцій: getppid, open, write, fork, exit й signal. Центральний процесор Периферійний процесор+-----------------------------+ +-----------------------------+| +------------+ | | +------------+ || | Процесори | | | | Процесори | || +-----+------+ | | +-----+------+ || ----+-------+------+------- | | ----+-------+-------------- || +---+----+ +-------+------+ | | +---+----+ || | Пам’ять| | Периферійні | | | | Пам’ять| || | | | пристрої | | | | | || +--------+ +--------------+ +-++-+ +--------+ |+-----------------------------+ ++ +-----------------------------+ | +-------------+---------------+ | +------------+ | Периферійний | | Процесори | | процесор | +-----+------+ | | ----+-------+-------------- | | +---+----+ | | | Пам’ять| | | | | | | +--------+ | +-----------------------------+ Малюнок 1.2 Конфігурація периферійної системи Так, наприклад, з метою одержання додаткової пам'яті процес може викликати для локального виконання функцію sbrk. Однак, якщо потрібні послуги центрального процесора, наприклад, щоб відкрити файл, ядро кодує інформацію до переданих у викликаній функції параметрах й умовах виконання процесу в якесь повідомлення, що посилає процесу-супутникові (Малюнок 1.3). Повідомлення містить у собі ознаку, з якої видно, що системна функція виконується процесом-супутником від імені клієнта, передані функції параметри йдані про середовище виконання процесу (наприклад, користувальницький і груповий коди ідентифікації), які для різних функцій різні. Частина повідомлення, що залишилася, являє собою дані змінної довжини (наприклад, складене ім'я файлу або дані, призначені для запису функцією write). Процес-супутник чекає надходження запитів від периферійного процесу; при одержанні запиту він декодує повідомлення, визначає тип системної функції, виконує її й перетворює результати у відповідь, що посилає периферійному процесу відповідь, крім результатів виконання системної функції, включає в себе повідомлення про помилку (якщо вона мала місце), номер сигналу й масив даних змінної довжини, що містить, наприклад, інформацію, прочитану з файлу. Периферійний процес припиняється до одержання відповіді, а одержавши його, робить розшифровку й передає результати користувачеві. Така загальна схема обробки звертань до операційної системи; тепер перейдемо до більш детального розгляду окремих функцій. Формат повідомлення+----------------+----------+---------------+--------------------+| Ознака виклику|Параметри |Дані про сере- | Складене ім’я || системної функ-|системної |довище виконан-|------- чи ------|| ції |функції |ня процеса | потік даних |+----------------+----------+---------------+--------------------+ Відповідь +------------+-----------+---------+---------------------+ | Результати |Повідомлен-| Номер | | | виконання |ня про | сигнала |---- Потік даних ---| | системної |помилку | | | | функції | | | | +------------+-----------+---------+---------------------+ Малюнок 1.3 Формати повідомлень Функція getppid досить проста, оскільки вона пов'язана із простими формами запиту й відповіді, якими обмінюються периферійний і центральний процесори. Ядро на периферійному процесорі формує повідомлення, що має ознаку, з якого видно, що запитуваною функцією є функція getppid, і посилає запит центральному процесору. Процес-супутник на центральному процесорі читає повідомлення з периферійного процесора, розшифровує тип системної функції, виконує її й одержує ідентифікатор свого родича. Потім він формує відповідь і передає його периферійному процесу, що перебуває в стані очікування на іншому кінці лінії зв'язку. Коли периферійний процесор получає відповідь, вона передає його процесу, що викликав системну функцію getppid. Якщо ж периферійний процес зберігає дані (такі, як ідентифікатор процесу-родича) у локальній пам'яті, йому взагалі не прийдеться зв'язуватися зі своїм супутником. Якщо виробляється звертання до системної функції open, периферійний процес посилає своєму супутникові відповідне повідомлення, що включає ім'я файлу й інші параметри. У випадку успіху процес-супутник виділяє індекс і точку входу в таблицю файлів, відводить запис у таблиці користувацьких дескрипторів файлу у своєму просторі й повертає дескриптор файлу периферійному процесу. Весь цей час на іншому кінці лінії зв'язку периферійний процес чекає відповіді. У нього в розпорядженні немає ніяких структур, які зберігали б інформацію про файл, який відкривається; дескриптор, що повертається функцією open, являє собою покажчик на запис у таблиці користувальницьких дескрипторів файлу, що належить процесу-супутникові. Результати виконання функції показані на малюнку 1.4. Якщо виробляється звертання до системної функції write, периферійний процесор формує повідомлення, що складається з ознаки функції write, дескриптора файлу й обсягу записуваних даних. Потім із простору периферійного процеса він по лінії зв'язку копіює дані процесу-супутникові. Процес-супутник розшифровує отримане повідомлення, читає дані з лінії зв'язку й записує їх у відповідний файл (в якості вказівника на індекс якого і запис про який в таблиці файлів використовується вміщений в повідомленні дескриптор); всі зазначені дії виконуються на центральному процесорі. По Центральний процесор Периферійний процесор+--------------------------------------+ +---------------------+| таблиця | | || користувацьких | | || дескрип- | | || таблиця таблиця торів | | || индексів файлів файла +--------+| | +---------+ || +-----+ +-----+ +-----+ |Процес- |----------| Процес | || | | | | | | |супутник|| | +---------+ || +-----+ +-----+ +-----+ +-+------+| | || | -+-+ | | ++- -+---+ | | || +-----+ | +-----+ |+-----+ дескрип- | | || | | +-+- -+-+| | тор файла | | || +-----+ +-----+ +-----+ | | || | | | | | | || +-----+ +-----+ | | || | | | | | | || +-----+ +-----+ | | |+--------------------------------------+ +---------------------+Малюнок 1.4. Виклик функції open з периферійного процесу закінченні роботи процес-супутник передає периферійному процесу посилку, що підтверджує прийом повідомлення й утримує кількість байт даних, успішно переписаних у файл. Операція read виконується аналогічно; супутника інформує периферійний процес про кількість реально прочитаних байт (у випадку читання даних з термінала або з каналу ця кількість не завжди збігається з кількістю, зазначеною в запиті). Для виконання як тієї, так й іншої функції може знадобитися багаторазове пересилання інформаційних повідомлень по мережі, що визначається обсягом даних, що пересилаються, і розмірами мережних пакетів. Єдиною функцією, що вимагає внесення змін при роботі на центральнім процесорі, є системна функція fork. Коли процес виконує цю функцію на ЦП, ядро вибирає для нього периферійний процесор і посилає повідомлення спеціальному процесу -серверу, інформуючи останній про те, що збирається приступити до вивантаження поточного процесу. Припускаючи, що серверприйняв запит, ядро за допомогою функції fork створює новий периферійний процес, виділяючи запис у таблиці процесів й адресний простір. Центральний процесор вивантажує копію процесу, що викликав функцію fork, на периферійний процесор, затираючи тільки що виділений адресний простір, породжує локальний супутник для зв'язку з новим периферійним процесом і посилає на периферію повідомлення про необхідність ініціалізації лічильника команд для нового процесу. Процес-супутник (на ЦП) є нащадком процесу, викликаного функцію fork; периферійний процес із технічної точки зору виступаєнащадком процесу-сервера, але по логіці він є нащадком процесу, що викликає функцію fork. Процес-сервер не має логічного зв'язку з нащадком по завершенні функції fork; єдине завдання сервера полягає в наданні допомоги при вивантаженні нащадка. Через сильний зв'язок між компонентами системи (периферійні процесори не мають у своєму розпорядженні автономію) периферійний процес й процес-супутник мають той самий код ідентифікації. Взаємозв'язок між процесами показаний на малюнку 13.5: безперервною лінією показаний зв'язок типу "родич-нащадок", пунктиром - зв'язок між рівноправними партнерами. Коли процес виконує функцію fork на периферійному процесорі, він посилає повідомлення своєму супутникові на ЦП, що і виконує після цього всю вищеописану послідовність дій. Супутник вибирає новий периферійний Центральний процесор Периферійний процесор +----------------------+ +----------------------+ | +------------------+ | | +------------------+ | | | Процес-породжувач|-------------| Процес-сервер | | | +---------+--------+ | | +------------------+ | | | | | | | | | | | | +---------+--------+ | | +------------------+ | | | Породжений супут-|-------------| Породжений про- | | | | ник | | | | цес | | | +------------------+ | | +------------------+ | +----------------------+ +----------------------+ Малюнок 1.5. Виконання функції fork на центральному процесорі процесор і робить необхідні приготування до вивантаження образа старого процесу: посилає периферійному процесу-родичеві запит на читання його образу, у відповідь на який на іншому кінці каналу зв'язку починається передача запитуваних даних. Супутник зчитує переданий образ і переписуєйого периферійному нащадкові. Коли вивантаження образа закінчується, процес-супутник виконує функцію fork, створюючи свого нащадка на ЦП, і передає значення лічильника команд периферійному нащадкові, щоб останній знав, з якої адреси починати виконання. Очевидно, було б краще, якби нащадок процесу-супутника призначався периферійному нащадкові як родич, однак в нашому випадку породжені процеси одержують можливість виконуватися й на інших периферійних процесорах, а не тільки на тім, на якому вони створені. Взаємозв'язок між процесами по завершенні функції fork показана намалюнку 1.6. Коли периферійний процес завершує свою роботу, він посилає відповідне повідомлення процесу-супутникові й той теж завершується. Від процеса-супутника ініціатива завершення роботи виходити не може. Центральний процесор+-------------------------------------------------------+| +-------------------+ +-----------------+ || |Супутник-породжувач+----------+ Супутник-нащадок| || +-------------------+ +-----------------+ || - - |+-------------------------------------------------------+- -+----------------------------+ +---------------------------+| - | | - || +------------------------+ | | +----------------------+ || | Периферійний породжувач| | | | Периферійни нащадок | || +------------------------+ | | +----------------------+ |+----------------------------+ +---------------------------+ Периферійний процесор Периферійний процесор Малюнок 1.6. Виконання функції fork на периферійному процесорі І в багатопроцесорній, і в однопроцесорній системах процес повинен реагувати на сигнали однаково: процес або завершує виконання системної функції до перевірки сигналів, або, навпроти, одержавши сигнал, не чекаючи виходить зі стану зупинки й різко перериває роботу системної функції, якщо це погоджується із пріоритетом, з яким він був припинений.Оскільки процес-супутник виконує системні функції від імені периферійного процесу, він повинен реагувати на сигнали, узгоджуючи свої дії з посліднім. Якщо в однопроцесорній системі сигнал змушує процес завершити виконання функції аварійно, процесу-супутникові в багатопроцесорній системі варто поводитися тим же чином. Те ж саме можна сказати й про той випадок,коли сигнал спонукає процес до завершення своєї роботи за допомогою функції exit: периферійний процес завершується й посилає відповідне повідомленняпроцесу-супутникові, що, зрозуміло, теж завершується. Коли периферійний процес викликає системну функцію signal, він зберігає поточну інформацію в локальних таблицях і посилає повідомлення своємусупутникові, інформуючи його про те, чи треба зазначений сигнал приймати або ж ігнорувати. Процесу-супутникові байдуже, чи виконувати перехоплення сигналу чи діяти за замовчуванням. Реакція процесу на сигнал залежить від трьох факторів (Малюнок 1.7): чи надходить сигнал під час виконання процесом системної функції, чи зроблено за допомогою функції signal вказівка про ігнорування сигналу, чи виникає сигнал на цьому ж периферійному процесорі або на якомусь іншому. Перейдемо до розгляду різних можливостей. +------------------------------------------------------------+| алгоритм sighandle /* алгоритм обробки сигналів */ || вхідна інформація: відсутній || вихідна інформація: відсутній || { || якщо (поточний процес є чиїмось супутником або || має прототип) || { || якщо (сигнал ігнорується) || повернути керування; || якщо (сигнал надійшов під час виконання системної || функції) || поставити сигнал перед процесом-супутником; || у противному випадку || послати повідомлення про сигнал периферійному || процесу; || } || у противному випадку /* периферійний процес */ || { || /* чи надійшов сигнал під час виконання системної || * функції чи ні || */ || послати сигнал процесу-супутнику; || } || } || || алгоритм satellite_end_of_syscall /* завершення систем- || * ної функції, виз- || * ваної периферійним || * процесом */ || вхідна інформація: відсутній || вихідна інформація: відсутній || { || якщо (під час виконання системної функції надійшло || переривання) || послати периферійному процесу повідомлення про || переривання, сигнал; || у противному випадку /* виконання системної функції не|| * переривалося */ || послати відповідь: включити прапор, що показує || поступлення сигналу; || } |+------------------------------------------------------------+ Малюнок 1.7. Обробка сигналів у периферійній системі Допустимо, що периферійний процес призупинив свою роботу на той час, поки процес-супутник виконує системну функцію від його імені. Якщо сигналвиникає в іншому місці, процес-супутник виявляє його раніше, ніж периферійний процес. Можливі три випадки. 1. Якщо чекаючи деякої події процес-супутник не переходив у стан зупинки, з якого він вийшов би після одержання сигналу, він виконує системну функцію до кінця, посилає результати виконання периферійному процесу й показує, який із сигналів ним був отриманий. 2. Якщо процес зробив вказівку про ігнорування сигналу даного типу, супутник продовжує додержуватися алгоритму виконання системної функції, не виходячи зі стану зупинки по longjmp. У відповіді, що посилається периферійному процесу, повідомлення про одержання сигналу буде відсутнє. 3. Якщо після одержання сигналу процес-супутник перериває виконання системної функції (по longjmp), він інформує про це периферійний процес і повідомляє йому номер сигналу. Периферійний процес шукає у відповіді, що надійшла, відомості про одержання сигналів й у випадку виявлення таких, робить обробку сигналів перед виходом із системної функції. Таким чином, поводження процесу в багатопроцесорній системі в точності відповідає його поводженню в однопроцесорній системі: він або завершує свою роботу, не виходячи з режиму ядра, або звертається до користувальницької функції обробки сигналу, або ігнорує сигнал й успішно завершує виконання системної функції. Периферійний процес Процес-супутник +---------------------------------------------------------- | Викликає системну функцію read - | Посилає повідомлення про виклик функції - | процесу-супутникові - | Припиняється до одержання - | відповіді від процесу-супутника Одержує повідомлення | - про виклик системної | - функції read | - Читає дані з тер- | - міналу | - Припиняється в | - очікуванні одержання | - порції даних | - - | - - | - Сигнал (користувач | - нажав клавішу "break") | - Виходить зі стану | - призупинки | - Припиняє виконання | - системної функції | - Посилає відповідь пери- | - ферійному процесу: | - виконання функції | - перервано | Виходить зі стану призупинки | Аналізує відповідь v Обробляє сигнал Малюнок 13.8. Переривання під час виконання системної функції Припустимо, наприклад, що периферійний процес викликає функцію читання з термінала, пов'язаного із центральним процесором, і припиняє свою роботу на час виконання функції процесом-супутником (Малюнок 1.8). Якщо користувач натискає клавішу переривання (break), ядро ЦП посилає процесові-супутнику відповідний сигнал. Якщо супутник перебував у стані зупинки чекаючи введення з термінала порції даних, він негайно виходитьіз цього стану й припиняє виконання функції read. У своїй відповіді на запит периферійного процесу супутник повідомляє код помилки й номер сигналу,відповідному перериванню. Периферійний процес аналізує відповідь й, оскільки в повідомленні говориться про надходження сигналу переривання, відправляєсигнал самому собі. Перед виходом з функції read периферійне ядро проводить перевірку надходження сигналів, виявляє сигнал переривання, що поступив від процесу-супутника, і обробляє його звичайним порядком. Якщо в результаті одержання сигналу переривання периферійний процес завершує свою роботу за допомогою функції exit, дана функція бере на себе турботу про знищення процеса-супутника. Якщо периферійний процес перехоплює сигнали про переривання, він викликає користувальницьку функцію обробки сигналів і по ви-ході з функції read повертає користувачеві код помилки. З іншого боку, якщо супутник виконує від імені периферійного процесу системну функціюstat, він не буде переривати її виконання при одержанні сигналу (функції stat гарантований вихід з будь-якої зупинки, оскільки для неї час очікування ресурсу обмежене). Супутник доводить виконання функції до кінця й повертає периферійному процесу номер сигналу. Периферійний процес посилає сигнал самому собі й одержує його на виході із системної функції. Якщо сигнал виник на периферійному процесорі під час виконання системної функції, периферійний процес буде перебувати в незнанні відносно того, чи повернеться до нього незабаром керування від процесу-супутника або ж останній перейде в стан зупинки на невизначений час. Периферійний процес посилає супутникові спеціальне повідомлення, інформуючи його про виникнення сигналу. Ядро на ЦП розшифровує повідомлення й посилає сигнал супутникові, реакція якого на одержання сигналу описана вище(аварійне завершення виконання функції або доведення його до кінця).Периферійний процес не може послати повідомлення супутникові безпосередньо, оскільки супутник зайнятий виконанням системної функції й не зчитує даніз лінії зв'язку. Якщо звернутися до приклада з функцією read, слід зазначити, що периферійний процес не має подання про те, чи чекає його ввід супутника даних з термінала або ж виконує інші дії. Периферійний процес посилає супутникові повідомлення про сигнал: якщо супутник перебуває в стані зупинки із пріоритетом, що допускає переривання, він негайно виходить із цьогостану й припиняє виконання системної функції; у противному випадку виконання функції доводить до успішного завершення. Розглянемо, нарешті, випадок надходження сигналу в час, не пов'язаний з виконанням системної функції. Якщо сигнал виник на іншому процесорі, супутник одержує його першим і посилає повідомлення про сигнал периферійному процесу, незалежно від того, чи стосується цей сигнал периферійного процесу чи ні. Периферійне ядро розшифровує повідомлення й посилає сигнал процесу, що реагує на нього звичайним порядком. Якщо сигнал виник на периферійному процесорі, процес виконує стандартні дії, не прибігаючи допослуг свого супутника. Коли периферійний процес посилає сигнал іншим периферійним процесам, він кодує повідомлення про виклик функції kill і посилає його процесу-супутникові, що виконує викликувану функцію локально. Якщо частина процесів, для яких призначений сигнал, має місцезнаходження на інших периферійних процесорах, сигнал одержать (і прореагують на його одержання вищеописаним способом) їхні супутники.

ЗВ'ЯЗОК ТИПУ NEWCASTLЕ

У попередньому розділі ми розглянули тип сильнозв’язаної системи, для якої характерна посилка всіх виникаючих на периферійному процесорі звернень до функцій підсистеми керування файлами на віддалений (центральний) процесор. Тепер перейдемо до розгляду систем з менш сильним зв'язком, які складаються з машин, що роблять звертання до файлів, що перебувають на других машинах. У мережі, що складається з персональних комп'ютерів і робітників станцій, наприклад, користувачі часто звертаються до файлів, розташованих на великій машині. У наступних двох розділах ми розглянемо такі конфігурації систем, у яких всі системні функції виконуються в локальних підсистемах, але при цьому є можливість звертання до файлів (через функції підсистеми керування файлами), розташованих на інших машинах. Для ідентифікації віддалених файлів у цих системах використається один з наступних двох шляхів. В одних системах у складене ім'я файлу додається спеціальний символ: компонента імені, що передує цьому символу, ідентифікує машину, інша частина імені - файл, що перебуває на цій машині.Так, наприклад, складене ім'я "sftig!/fs1/mjb/rje" ідентифікує файл "/fs1/mjb/rje", що перебуває на машині "sftig". Такасхема ідентифікації файлу відповідає угоді, встановленій програмою uucp щодо передачі файлів між системами типу UNIX. В іншій схемі віддалені файли ідентифікуються додаванням до імені спеціального префіксу, наприклад: /../sftig/fs1/mjb/rje де "/../" - префікс, що свідчить про те, що файл віддалений; друга компонента імені файлу є ім'ям віддаленої машини. У даній схемі використовується звичний синтаксис імен файлів у системі UNIX, тому на відміну від першої схеми тут користувальницьким програмам немає необхідності пристосовуватися до використання імен, що мають незвичайну конструкцію (див. [Pike85]). Процес-клієнт Процес-сервер+-----------------------------+ +----------------------------+| Таблиця | | Процес- || Сі-бібліотека відкритих | | супутник Запит || файлів | | (користу- на читання|| +------+ | | вацький | | || +------------------ | | | рівень) | | || | +------+ | | | | || | локальний | | | | +-------------+ | || | +------+ | | | | || | +-------- | | | | | || | | +------+ | | | | || | | | | | | | | || | | +------+ | | | | || | +-----+ | | | | |+----+------------------------+ +----+-----------------+-----+ | | віддалений | |+----+------------------------+ +----+-----------------+-----+| | Мережний | | | Мережний || Ядро інтерфейс | | Ядро інтерфейс || | | | | |+--------------------+--------+ +----------------------+-----+ | мережа | +-------------------------------------+ Малюнок 1.9. Формулювання запитів до файлового сервера (процесору) Всю частину, що залишилася, ми присвятимо розгляду моделі системи, яка використовує зв'язок типу Newcastle, у якій ядро не займається розпізнаванням віддалених файлів; ця функція повністю покладає на підпрограми з стандартної Сі-бібліотеки, що виконують у цьому випадку роль системного інтерфейсу. Ці підпрограми аналізують перший компонент імені файлу, у 2 описаних способах ідентифікації утримуюча ознака дальності файла. У цьому складається відступ від заведеного порядку, при якому бібліотечні підпрограми не займаються синтаксичним розбором імен файлів. Намалюнку 13.9 показано, яким чином формулюються запити до файлового серверу. Якщо файл локальний, ядро локальної системи обробляє запит звичайним способом. Розглянемо зворотній випадок: open("/../sftig/fs1/mjb/rje/file",O_RDONLY); Підпрограма open із Сі-бібліотеки аналізує перші два компоненти складного імені файлу й дізнається, що файл варто шукати на віддаленій машині "sftig". Щоб мати інформацію про те, чи був раніше в процесі зв'язок з даною машиною, підпрограма заводить спеціальну структуру, у якій запам’ятовує цей факт, і у випадку негативної відповіді встановлює зв'язок з файловим сервером, що працює на віддаленій машині. Коли процес формулює свій перший запит на дистанційну обробку, віддалений сервер підтверджує запит, якщо буде потреба веде запис у поля користувальницького й групового кодів ідентифікації й створює процес-супутник, що буде відрізнятися від імені процесу-клієнта. Щоб виконувати запити клієнта, супутник повинен мати на віддаленій машині тіж права доступу до файлів, що й клієнт. Інакше кажучи, користувач "mjb" повинен мати і до віддалених, і до локальних файлів однакові права доступу. На жаль, не виключена можливість того, що код ідентифікації клієнта "mjb" може збігтися з кодом ідентифікації іншого клієнта віддаленої машини. Таким чином, адміністраторам систем на працюючих у мережі машинах треба або стежити за призначенням кожному користувачеві коду ідентифікації, унікального для всієї мережі, або в момент формулювання запиту на мережне обслуговування виконувати перетворення кодів. Якщо це не буде зроблено, процес-супутник буде мати на віддаленій машині права іншого клієнта. Більш делікатним питанням є одержання відносно роботи з віддаленими файлами прав суперкористувача. З одного боку, клієнт-суперкористувач не повинен мати ті ж права відносно віддаленої системи, щоб не вводити в оману засобу захисту віддаленої системи. З іншого боку, деякі із програм, якщо їм не надати права суперкористувача, просто не зможуть працювати. Прикладом такої програми є програма mkdir, що створює новий каталог. Віддалена система не дозволила бклієнтові створювати новий каталог, оскільки на видаленні права суперкористувача не діють. Проблема створення віддалених каталогів служить серйозноюпідставою для перегляду системної функції mkdir убік розширення її можливостей в автоматичному встановленні всіх необхідних користувачеві зв'язків. Проте, одержання setuid-програмами (до яких відноситься йпрограма mkdir) прав суперкористувача стосовно віддалених файлів все ще залишається загальною проблемою, що вимагає свого рішення. Можливо, що найкращим рішенням цієї проблеми було б установлення для файлів додаткових характеристик, що описують доступ до них з боку віддалених суперкористувачів; на жаль, це зажадало б внесення змін у структуру дискового індексу (у частині додавання нових полів) і породило б занадто великий безлад в існуючих системах. Якщо підпрограма open завершується успішно, локальна бібліотека залишає відповідну оцінку в доступній для користувача структурі, утримуюча адреса мережного вузла, ідентифікатор процесу-супутника, дескриптор файлу й іншу аналогічну інформацію. Бібліотечні підпрограми read й write установлюють, виходячи з дескриптора, чи є файл віддаленим, і ввипадку позитивної відповіді посилають супутникові повідомлення. Процес-клієнт взаємодіє зі своїм супутником у всіх випадках звертання до системнихфункцій, що бідують у послугах віддаленої машини. Якщо процес звертається до 2 файлів, розташованих на одній і тій же віддаленій машині, він користується одним супутником, але якщо файли розташовані на різних машинах, використаються уже два супутники: по одному на кожній машині. Два супутники використаються й втому випадку, коли до файлу на віддаленій машині звертаються два процеси. Визиваючи системну функцію через супутника, процес формує повідомлення, включаючи в себе номер функції, ім'я шляху пошуку й іншу необхідну інформацію, аналогічну до тої, котра входить у структуру повідомлення в системі з периферійними процесорами. Механізм виконання операцій над поточним каталогом більш складний. Коли процес вибирає в якості поточний віддалений каталог, бібліотечна підпрограма посилає відповідне повідомлення супутникові, що змінює текучий каталог, при цьому підпрограма запам'ятовує, що каталог віддалений. У всіх випадках, коли ім'я шляху пошуку починається із символу, відмінного від похилої риски (/), підпрограма посилає це ім'я на віддалену машину, де процес-супутник прокладає маршрут, починаючи з поточного каталогу. Якщо текучий каталог - локальний, підпрограма просто передає ім'я шляху пошуку ядру локальної системи. Системна функція chroot відносно віддаленого каталогу виконується схоже, але при цьому її виконання для ядра локальної системи проходить непоміченим; строго говорячи, процес може залишити цю операцію без уваги, оскільки тільки бібліотека фіксує її виконання. Коли процес викликає функцію fork, якій відповідає бібліотечна підпрограма, посилається повідомлення кожному супутникові. Процеси-супутники виконуютьоперацію розгалуження й посилають ідентифікатори своїх нащадків клієнтам-родичам. Процес-клієнт запускає системну функцію fork, що передає управління породжуваному нащадкові; локальний нащадок веде діалог з віддаленим нащадком-супутником, адреси якого зберегла бібліотечна підпрограма. Таке трактування функції fork полегшує процесам-супутникам контроль над відкритимифайлами й поточними каталогами. Коли процес, що працює з віддаленими файлами, завершується (викликаючи функцію exit), підпрограма посилає повідомлення всім його віддаленим супутникам, щоб вони після одержання повідомлення проробили те ж саме. Перевага зв'язку типу Newcastle полягає в тому, що звернення процесу до віддалених файлів стає "прозорим" (непомітним для користувача), при цьому в ядро системи ніяких змін вносити не потрібно. Однак, даній розробці властивий і ряд недоліків. Насамперед, при її реалізації можливе зниження продуктивності системи. У зв'язку з використанням розширеноїСі-бібліотеки розмір використовуваної кожним процесом пам'яті збільшується, також якщо процес не звертається до віддалених файлів; бібліотека дублює функції ядра й вимагає для себе більше місця в пам'яті. Збільшення розміру процесів приводить до подовження тривалості періоду запуску й може визвати більшу конкуренцію за ресурси пам'яті, створюючи умови для більшого часовоготого вивантаження й підкачування завдань. Локальні запити будуть виконуватися повільніше через збільшення тривалості кожного звертання до ядра, уповільнення може грозити й обробці віддалених запитів, витрати по пересиланню яких по мережі збільшуються. Додаткова обробка віддалених запитів на користувацькому рівні збільшує кількість перемикань контексту, операцій повивантаженню й підкачуванню процесів. Нарешті, для того, щоб звертатися до віддалених файлів, програми повинні бути перекомпільовані з використанням новихбібліотек; старі програми й поставлені об'єктні модулі без цього робити з віддаленими файлами не зможуть. Всі ці недоліки відсутні в системі, що описана в наступному розділі.

quot;ПРОЗОРІ" РОЗПОДІЛЕНІ ФАЙЛОВІ СИСТЕМИ

Термін "прозорий розподіл" означає, що користувачі, що працюють на одній машині, можуть звертатися до файлів, що перебувають на іншій машині, не усвідомлюючи того, що тим самим вони перетинають машинні границі, подібно тому, як на своїй машині вони при переході від одної файлової системи до іншої переходять точки монтування. Імена, по яких процеси звертаються до файлів, що находяться на віддалених машинах, схожі на імена локальних файлів: відрізняючі символи в них відсутні. У конфігурації, показаній на малюнку 13.10, каталог "/usr/src", що належить машині B, "вмонтований" у каталог "/usr/src", що належить машині A. Така конфігурація є зручною у тому випадку, якщо в різних системах передбачається використати один й той же вихідний код системи, що традиційно перебуває в каталозі "/usr/src". Користувачі, що працюють на машині A, можуть звертатися до файлів, розташованих на машині B, використовуючи звичний синтаксис написання імен файлів (наприклад: "/usr/src/cmd/login.c"), і ядро вже саме вирішує питання, є файл віддаленим або ж локальним. Користувачі, що працюють на машині B, мають доступ до своїх локальних файлів (не підозрюючи про те, що до цих же файлів можуть звертатися й користувачі машини A), але, у свою чергу, не мають доступу до файлів, що перебувають на машині A. Звичайно, можливі й інші варіанти, частково такі, у яких всі віддалені системи монтуються в корені локальної системи, завдяки чому користувачі одержують доступ до всіх файліву всіх системах. Наявність подібності між монтуванням локальних файлових систем й відкриттям доступу до віддалених файлових систем послужило приводом для адаптаціїфункції mount стосовно віддалених файлових систем. У цьому випадку ядро одержує у своє розпорядження таблицю монтування розширеного формату. Виконуючи функцію mount, ядро організує мережний зв'язок з віддаленою машиною й зберігає в таблиці монтування інформацію, що характеризує даний зв'язок. Цікава проблема пов'язана з іменами шляхів, що включають "..". Якщо процес робить поточний каталог з віддаленої файлової системи, наступне користування в імені символів ".." скоріше поверне процес у локальну файлову систему, чим дозволить звертатися до файлів, розташованих вище поточного каталогу. Повертаючись знову до Малюнка 13.10, відзначимо, що коли процес, що належить машині A, вибравши попередньо в якості поточний каталог "/usr/src/cmd", розташований у віддаленій файловій системі, виконає команду cd../../..поточним каталогом стане кореневий каталог, що належить машині A, а не машині B. Алгоритм name, що працює в ядрі віддаленої системи, одержавши послідовність символів "..", перевіряє, чи є визиваючий процес агентом процесу-клієнта, і у випадку позитивної відповіді встановлює, чи клієнт пояснює поточний робочий каталог як корінь віддаленої файловоїсистеми. Машина A Машина B+-----------------------------+ +-----------------------------+| / | | / || | | | | || +--------+--------+ | | +-----------+-----------+ || | | | | | | | || bin usr | | usr bin etc || | | | | | || +----+----+ +----+--+ | | +-і-і-і-+ || | | | | | | | | ||login mail bin src| +-і->src bin || | | | | | | || +---+---+ | | | | +------+-----+ || | | | | | | | | | || troff vi | | | | lib cmd uts || | | | | | || | | | | +---+---+ || | | | | | | || | | | | login.c mail.c |+---------------------------|-+ | +-----------------------------+ +---+ Малюнок 1.10. Файлові системи після віддаленого монтування Зв'язок з віддаленою машиною приймає одну із двох форм: виклик віддаленої процедури або виклик віддаленої системної функції. У першій формі кожна процедура ядра, що має справу з індексами, перевіряє, чи вказує індекс на віддалений файл, і якщо це так, посилає на віддалену машину запит на виконання зазначеної операції. Дана схема природно вписується вабстрактну структуру підтримки файлових систем різних типів, описану заключній частині глави 5. Таким чином, звертання до віддаленого файлу може ініціювати пересилання по мережі декількох повідомлень, кількість яких визначається кількістю операцій над файлом, і збільшенням часу відповіді на запит з обліком прийнятого в мережі часу очікування. Кожен набір віддалених операцій містить у собі, по крайній мірі, дії по блокуванню індексу, підрахунку посилань і т.п. З метою вдосконалення моделі пропонувалися різні оптимізаційні рішення, зв’язані з об'єднанням декількох операцій в один запит (повідомлення) і з буферизацією найбільш важливих даних (див. [Sandberg85]). Сервер Клієнт (процес/процесор)+--------------------+ +----------------------------------------+| таблиця | | таблиця таблиця таблиця || індексів +-------+ | | індексів файлів користу- || +-----+ |спутник|-| | +-----+ +-----+ вацьких || | | +-+-----+ |- | | | | | || +-----+ | | - +-----+ +-----+ дескрип- +-------+|| | | | +-|---і+- -+-+ | | торів +--+Процесс +-----+ | | | | +-----+ | +-----+ файлу | +-------+|| | | | | | | | | +-+- -++ +-----+ | || +-----+ | | | | +-----+ +----+|| | | || | | | | | | | | | || +-----+ |дескриптор || +-----+ | | | | +-----+ +-----++-+- -+-+файлу || | +----+-----+ | | | | | | +-----+ || +-----+ | | +-----+ +-----+ | | || | | +-----+ |+--------------------+ +----------------------------------------+ Малюнок 1.11 Відкриття віддаленого файлу Розглянемо процес, що відкриває віддалений файл "/usr/src/cmd/login.c", де "src" - точка монтування. Виконуючи синтаксичний розбір імені файлу (за схемою namei-iget), ядро виявляє, що файл віддалений, і посилає на машину, де він перебуває, запит на одержання заблокованого індексу. Одержавши бажану відповідь, локальне ядро створює в пам’яті копію індексу, що листується з віддаленим файлом. Потім ядро виконує перевірку наявності необхідних прав доступу до файлу (на читання, наприклад), пославши на віддалену машину ще одне повідомлення. Взаємозв'язок між структурами даних ядра по завершенні алгоритму open показана на Малюнку 1.11. Якщо клієнт викликає системну функцію read, ядро клієнта блокує локальний індекс, надсилає запит на блокування віддаленого індексу, запитна читання даних, копіює дані в локальну пам'ять, надсилає запит на звільнення віддаленого індексу й звільняє локальний індекс. Така схема відповідає семантиці існуючого однопроцесорного ядра, але частота користування мережі (кілька обігів на кожну системну функцію) знижує продуктивність всієї системи. Однак, щоб зменшити потік повідомлень вмережі, в один запит можна поєднувати кілька операцій. У прикладі з функцією read клієнт може послати серверу один загальний запит на "читання", а сервер при його виконанні сам приймає рішення на захоплення й звільнення індекса. Скорочення мережного трафіка можна домогтися й шляхом використання віддалених буферів (про що ми вже говорили вище), але при цьому потрібно подбати про те, щоб системні функції роботи з файлами, що використають ці буфери, виконувалися належним чином. При другій формі зв'язку з віддаленою машиною (виклик віддаленої системної функції) локальне ядро виявляє, що системна функція має відношення до віддаленого файлу, і посилає зазначені в її виклику параметри на віддаленусистему, що виконує функцію й повертає результати клієнтові. Машина клієнта одержує результати виконання функції й виходить зі стану виклику. Більшість системних функцій може бути виконане з використанням тільки одного мережного запиту з одержанням відповіді через досить непоганий час, але в таку модель уписуються не всі функції. Так, наприклад, по одержанні деяких сигналів ядро створює для процесу файл із ім'ям "core". Створення цього файлу не пов'язане з конкретною системною функцією, а завершує виконання декількох операцій, таких як створення файлу, перевірку прав доступу й виконання ряду операцій запису. У випадку із системною функцією open запит на виконання функції, що посилається на віддалену машину, містить у собі частину імені файлу, що залишилася після виключення компонентів імені шляху пошуку, що відрізняють віддалений файл, а також різні прапори. У розглянутому раніше прикладі з відкриттям файлу "/usr/src/cmd/login.c" ядро посилає на віддалену машину ім'я "cmd/login.c". Повідомлення також містить у собі розпізнавальні дані, такі як користувацький і груповий коди ідентифікації, необхідні для перевірки прав доступу до файлів на віддаленій машині. Якщо з віддаленої машини надходить відповідь, що свідчить про успішне виконання функції open, локальне ядро вибирає вільний індекс у пам'яті локальної машини й позначає його як індекс віддаленого файлу, зберігає інформацію про віддалену машину і віддалений індекс й за заведеним порядком виділяє новий запис у таблиці файлів. В порівнянні з реальним індексом на віддаленій машині індекс, що належить локальній машині, є формальним, що не порушує конфігурацію моделі; в цілому збігається з конфігурацією, використовуваною при виклику віддаленої процедури (Малюнок 13.11). Якщо викликувана процесом функція звертається до віддаленого файлу по його дескрипторі, локальне ядро довідається з індексу (локального) про те, що файл віддалений, формулює запит, що включає в себе викликувану функцію, і посилає його на віддалену машину. У запиті втримується покажчик на віддалений індекс, по якому процес-супутник зможе ідентифікувати сам віддалений файл. Одержавши результат виконання будь-якої системної функції, ядро може для його обробки вдатися до послуг спеціальної програми (по завершенні якої ядро закінчить роботу з функцією), тому що не завжди локальна обробка результатів, застосовувана в однопроцесорній системі, підходить для системи з кількома процесорами. Внаслідок цього можливі зміни в семантиці системних алгоритмів, спрямовані на забезпечення підтримки виконання вилучених системних функцій. Однак, при цьому в мережі циркулює мінімальний потік повідомлень, що забезпечує мінімальний час реакції системи на поступаючі запити.