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

Термін "прозорий розподіл" означає, що користувачі, що працюють на одній машині, можуть звертатися до файлів, що перебувають на іншій машині, не усвідомлюючи того, що тим самим вони перетинають машинні границі, подібно тому, як на своїй машині вони при переході від одної файлової системи до іншої переходять точки монтування. Імена, по яких процеси звертаються до файлів, що находяться на віддалених машинах, схожі на імена локальних файлів: відрізняючі символи в них відсутні. У конфігурації, показаній на малюнку 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). Якщо викликувана процесом функція звертається до віддаленого файлу по його дескрипторі, локальне ядро довідається з індексу (локального) про те, що файл віддалений, формулює запит, що включає в себе викликувану функцію, і посилає його на віддалену машину. У запиті втримується покажчик на віддалений індекс, по якому процес-супутник зможе ідентифікувати сам віддалений файл.

Одержавши результат виконання будь-якої системної функції, ядро може для його обробки вдатися до послуг спеціальної програми (по завершенні якої ядро закінчить роботу з функцією), тому що не завжди локальна обробка результатів, застосовувана в однопроцесорній системі, підходить для системи з кількома процесорами. Внаслідок цього можливі зміни в семантиці системних алгоритмів, спрямовані на забезпечення підтримки виконання вилучених системних функцій. Однак, при цьому в мережі циркулює мінімальний потік повідомлень, що забезпечує мінімальний час реакції системи на поступаючі запити.