Файловые системы с перекрытием

Предположим, что у вас очень медленное сетевое соединение, и вы смонтировали поверх него сетевую файловую систему. Вы замечаете, что некоторый файлы используются достаточно часто, и хотели бы, чтобы эти файлы неким волшебным способом «кешировались» на вашей машине, но увы и ах, проектировщики сетевой файловой системы это почему-то не предусмотрели. И тогда вы решаете самостоятельно написать кеширующую файловую систему (назовем ее, например,

) и поместить ее поверх сетевой файловой системы. Вот как это будет смотреться с позиции клиента:

Обе файловые системы,

(сетевая файловая система) и ваша кэшированная файловая система () регистрируются под одним и тем же префиксом, «» уже упомянули выше, в QNX/Neutrino это нормально и абсолютно законно.

Предположим, что ваша система только что стартовала, и в вашей кэшированной файловой системе еще ничего нет. Клиентская программа пробует открыть какой-нибудь файл — скажем

. Ваша кэшированная файловая система находится «перед» сетевой файловой системой (я потом покажу вам, как это сделать, когда мы будем обсуждать реализацию администратора ресурса).

Клиентский вызов open выполняет свои обычные действия:

1. Спрашивает администратор процессов: «К кому обратиться по поводу файла

?»

2. Получает ответ от администратора процессов: «Поговори сначала с

, а потом с ».

Обратите внимание, что здесь администратор процессов возвращает две четверки ND/PID/CHID/handle — одну для файловой системы

e и одну для файловой системы . Это критично.

Далее функция open делает следующее:

1. Направляет сообщение файловой системе

. «Я бы хотел открыть файл на чтение, пожалуйста.»

2. Получает ответ от файловой системы

: «Сожалею, но я никогда о таком не слышала.»

Здесь становится ясно, что с администратором файловой системы

клиентской функции open не повезло. Файл не существует! Однако, вызов open знает, что он получил список из двух четверок ND/PID/CHID/handle, и поэтому пробует второй вариант:

1. Направляет сообщение файловой системе

: «Я бы хотел открыть файл на чтение, пожалуйста.»

2. От файловой системы приходит ответ: «Запросто, никаких проблем!»

Теперь, после того как у функции open есть EOK («никаких проблем»), она возвращает дескриптор файла. Все дальнейшие операции клиент выполняет непосредственно с администратором сетевой файловой системы

.

Имя пути разрешается только один раз — во время вызова функции open. Это означает, что как только мы успешно открыли нужный администратор ресурса, все дальнейшие вызовы, работающие с дескрипторами файлов, будут идти через него.

Так когда же вступает в игру наша кеширующая файловая система

? Ну, допустим, пользователь закончил считывание файла (файл теперь загружен в текстовый редактор). Когда файл понадобится сохранить, произойдет та же самая последовательность действий, но возникнет один любопытный поворот:

1. Сообщение администратору процессов: «С кем я должен переговорить насчет файла

?»

2. Ответ администратора процессов: «Поговори сначала с

, а затем с ».

3. Сообщение

: «Мне хотелось бы открыть файл на запись, пожалуйста».

4. Ответ от

: «Запросто, нет проблем».

Обратите внимание на то, что на 3 этапе мы открыли файл на запись, а не на чтение, как в первый раз. Поэтому не удивительно, что

на этот раз разрешает эту операцию (этап 4).

Еще более интересные события происходят, когда мы повторно пытаемся прочитать этот файл:

1. Сообщение администратору процессов: «С кем я должен переговорить насчет файла

?»

2. Ответ администратора процессов: «Поговори сначала с

, а затем с ».