<<
>>

Совместно используемые файлы

Когда над проектом вместе работают несколько пользователей, зачастую возникает потребность в совместном использовании файлов. Поэтому нередко представляется удобным, чтобы совместно используемые файлы одновременно появлялись в различных каталогах, принадлежащих разным пользователям.
На рис. 4.13 еще раз показана файловая система, изображенная на рис. 4.4, только теперь один из файлов, принадлежащих пользователю C, представлен также в одном из каталогов, принадлежащих пользователю B. Установленное при этом отношение между каталогом, принадлежащим B, и совместно используемыми файлами называется связью. Теперь сама файловая система представляет собой не дерево, а ориентированный ациклический граф (Directed Acyclic Graph (DAG)). Потребность в том, чтобы файловая система была представлена как DAG, усложняет ее обслуживание, но такова жизнь.

Совместно используемый файл

При всем удобстве совместное использование файлов вызывает ряд проблем.

Для начала следует заметить: если собственно каталоги содержат адреса всех дисковых блоков файла, то при установке связи с файлом они должны быть скопированы в каталог, принадлежащий пользователю B. Если кто-либо из пользователей, B или C, чуть позже добавит к файлу какие-то новые данные, то новые блоки попадут в список каталога, принадлежащего только тому пользователю, который производил дополнение. Другому пользователю изменения будут не видны, и совместное использование потеряет всякий смысл.

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

Такой подход используется в UNIX (где в качестве такой структуры данных выступает i-узел).

Второе решение заключается в том, что каталог пользователя B привязывается к одному из файлов пользователя C, заставляя систему создать новый файл типа LINK и включить этот файл в каталог пользователя B. Новый файл содержит только имя того файла, с которым он связан. Когда пользователь B читает данные из связанного файла, операционная система видит, что файл, из которого они считываются, относится к типу LINK, находит в нем имя файла и читает данные из этого файла. Этот подход в отличие от традиционной (жесткой) связи называется символической ссылкой.

У каждого из этих методов имеются недостатки. В первом методе, когда пользователь B устанавливает связь с совместно используемым файлом, в i-узле владельцем файла числится пользователь C. Создание связи не приводит к изменению владельца (рис. 4.14), а увеличивает показания счетчика связей в i-узле, благодаря чему система знает, сколько записей в каталогах указывает на файл в данный момент.

Если впоследствии пользователь C попытается удалить файл, система сталкивается с проблемой. Если она удаляет файл и очищает i-узел, то в каталоге у пользователя B будет запись, указывающая на неверный i-узел. Если i-узел чуть позже будет назначен

а б в

Рис. 4.14. Ситуация, сложившаяся: а — перед созданием связи; б — после создания связи; в — после того как владелец (исходный пользователь) удаляет файл

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

Единственное, что можно сделать, — это удалить запись в каталоге пользователя С, но оставить нетронутым Ьузел, установив его счетчик связей в 1 (см. рис. 4.14, в). В результате возникнет ситуация, когда В является единственным пользователем, имеющим в своем каталоге ссылку на файл, которым владеет пользователь С. Если в системе ведется учет использования ресурсов или выделяются какие-то квоты, то пользователь С будет по-прежнему получать счета за этот файл, до тех пор пока пользователь В не примет решение его удалить. Тогда счетчик будет сброшен до нуля, а файл — удален.

При использовании символической ссылки такой проблемы не возникает, поскольку указатель на Ьузел есть только у владельца файла. А у пользователей, создавших ссылку на файл, есть только пути к файлам и нет указателей на Ьузлы. Файл при удалении его владельцем уничтожается. Последующие попытки использовать этот файл при помощи символической ссылки не будут иметь успеха, так как система не сможет найти файл. Удаление символической ссылки никак на файл не повлияет.

Проблема использования символических ссылок заключается в дополнительных издержках. Файл, в котором содержится путь, должен быть прочитан, затем путь должен быть разобран и покомпонентно пройден, пока не будет достигнут Ьузел. Все эти действия могут потребовать многократных дополнительных обращений к диску. Более того, для каждой символической ссылки нужен дополнительный Ьузел, равно как и дополнительный дисковый блок для хранения пути, хотя, если имя пути не слишком длинное, система в порядке оптимизации может хранить его в самом ^узле. Преимущество символических ссылок заключается в том, что они могут использоваться для связи с файлами, которые находятся на удаленных компьютерах в любой точке земного шара. Для этого нужно лишь в дополнение к пути к файлу указать сетевой адрес машины, на которой он находится.

Символические или иные ссылки вызывают и еще одну проблему. Когда разрешается использование ссылок, могут появиться два и более путей к файлу. Программы, начинающие свою работу с заданного каталога и ведущие поиск всех файлов в этом каталоге и его подкаталогах, могут обнаруживать файл, на который имеются ссылки, по нескольку раз. Например, программа, архивирующая все файлы в каталоге и всех его подкаталогах на магнитную ленту, может сделать множество копий файла, на который имеются ссылки. Более того, если потом эта лента будет прочитана на другой машине, то вместо создания ссылок на файл он может быть повторно скопирован, если только программа архивации не окажется достаточно «умной».

4.3.5.

<< | >>
Источник: Э. ТАНЕНБАУМ Х. БОС. СОВРЕМЕННЫЕ ОПЕРАЦИОННЫЕ СИСТЕМ Ы 4-е ИЗДАНИЕ. 2015

Еще по теме Совместно используемые файлы:

  1. Приложение СЛОВАРЬ ТЕРМИНОВ, ИСПОЛЬЗУЕМЫХ В АКТАХ ИНФОРМАЦИОННОГО ЗАКОНОДАТЕЛЬСТВА
  2. 3.3. Научно-технические методы и средства, используемые для лабораторного исследования объектов
  3. 3.2. Научно-технические средства и методы криминалистической техники, используемые для обнаружения, фиксации и изъятия доказательств
  4. 12.3.3. Совместное путешествие
  5. ДЕЯТЕЛЬНОСТЬ СОВМЕСТНАЯ
  6. 3. Проекты совместного внедрения
  7. О недостатках совместного сна
  8. Статья 1130. Договор о совместной деятельности
  9. § 3. Право общей совместной собственности
  10. Статья 1131. Форма и условия договора о совместной деятельности
  11. § 3. Право общей совместной собственности
  12. Раздел XV. Обязательства из совместной деятельности
  13. Статья 368. Право общей совместной собственности