Архитектура операционной системы UNIX
Шрифт:
Рисунок 5.27. Алгоритм демонтирования файловой системы
Рисунок 5.28. Файлы в дереве файловой системы, связанные с помощью функции link
5.15 LINК
Системная функция link связывает файл с новым именем в структуре каталогов файловой системы, создавая для существующего индекса новую запись в каталоге. Синтаксис вызова функции link:
link(source file name, target file name);
где source file name — существующее имя файла, а target file name — новое (дополнительное) имя, присваиваемое файлу после выполнения функции link. Файловая система хранит имя пути поиска для каждой связи, имеющейся у файла, и процессы могут обращаться к файлу по любому из этих имен. Ядро не знает, какое из имен файла является его подлинным именем, поэтому имя файла специально не обрабатывается. Например, после выполнения набора функций:
link("/usr/src/uts/sys", "/usr/include/sys");
link("/usr/include/realfile.h", "/usr/src/uts/sys/testfile.h");
на один и тот же файл будут указывать три имени пути поиска: «/usr/src/uts/sys/testfile.h», «/usr/include/sys/testfile.h» и «/usr/include/realfile» (см. Рисунок 5.28).
Ядро позволяет суперпользователю (и только ему) связывать каталоги, упрощая написание программ, требующих пересечения дерева файловой системы. Если бы это было разрешено произвольному пользователю, программам, пересекающим иерархическую структуру файлов, пришлось бы заботиться о том, чтобы не попасть в бесконечный цикл в том случае, если пользователь связал каталог с вершиной, стоящей ниже в иерархии. Предполагается, что суперпользователи более осторожны в указании таких связей. Возможность связывать между собой каталоги должна была поддерживаться в ранних версиях системы, так как эта возможность требуется для реализации команды mkdir, которая создает новый каталог. Включение функции mkdir устраняет необходимость в связывании каталогов.
Рисунок 5.29. Алгоритм связывания файлов
На Рисунке 5.29 показан алгоритм функции link. Сначала ядро, используя алгоритм namei, определяет местонахождение индекса исходного файла, увеличивает значение счетчика связей в индексе, корректирует дисковую копию индекса (для обеспечения согласованности) и снимает с индекса блокировку. Затем ядро ищет файл с новым именем; если он существует, функция link завершается неудачно и ядро восстанавливает прежнее значение счетчика связей, измененное ранее. В противном случае ядро находит в родительском каталоге свободную запись для файла с новым именем, записывает в нее новое имя и номер индекса исходного файла и освобождает индекс родительского каталога, используя алгоритм iput. Поскольку файл с новым именем ранее не существовал, освобождать еще какой-нибудь индекс не нужно. Ядро, освобождая индекс исходного файла, делает заключение: счетчик связей в индексе имеет значение, на 1 большее, чем то значение, которое счетчик имел перед вызовом функции, и обращение к файлу теперь может производиться по еще одному имени в файловой системе. Счетчик связей хранит количество записей в каталогах, которые (записи) указывают на файл, и тем самым отличается от счетчика ссылок в индексе. Если по завершении выполнения функции link к файлу нет обращений со стороны других процессов, счетчик ссылок в индексе принимает значение, равное 0, а счетчик связей — значение, большее или равное 2.
Например, выполняя функцию, вызванную как:
link("source", "/dir/target");
ядро обнаруживает индекс для файла «source», увеличивает в нем значение счетчика связей, запоминает номер индекса, скажем 74, и снимает с индекса блокировку. Ядро также находит индекс каталога «dir», являющегося родительским каталогом для файла «target», ищет свободное место в каталоге «dir» и записывает в него имя файла «target» и номер индекса 74. По окончании этих действий оно освобождает индекс файла «source» по алгоритму iput. Если значение счетчика связей файла «source» раньше было равно 1, то теперь оно равно 2.
Стоит упомянуть о двух тупиковых ситуациях, явившихся причиной того, что процесс снимает с индекса исходного файла блокировку после увеличения значения счетчика связей. Если бы ядро не снимало с индекса блокировку, два процесса, выполняющие одновременно следующие функции:
процесс A: link("a/b/c/d", "e/f/g");
процесс B: link("e/f", "a/b/c/d/ee");
зашли бы в тупик (взаимная блокировка). Предположим, что процесс A обнаружил индекс файла «a/b/c/d» в тот самый момент, когда процесс B обнаружил индекс файла «e/f». Фраза «в тот же самый момент» означает, что системой достигнуто состояние, при котором каждый процесс получил искомый индекс. (Рисунок 5.30 иллюстрирует стадии выполнения процессов.) Когда же теперь процесс A попытается получить индекс файла «e/f», он приостановит свое выполнение до тех пор, пока индекс файла «f» не освободится. В то же время процесс B пытается получить индекс каталога «a/b/c/d» и приостанавливается в ожидании освобождения индекса файла «d». Процесс A будет удерживать заблокированным индекс, нужный процессу B, а процесс B, в свою очередь, будет удерживать заблокированным индекс, нужный процессу A. На практике этот классический пример взаимной блокировки невозможен благодаря тому, что ядро освобождает индекс исходного файла после увеличения значения счетчика связей. Поскольку первый из ресурсов (индекс) свободен при обращении к следующему ресурсу, взаимная блокировка не происходит.
Следующий пример показывает, как два процесса могут зайти в тупик, если с индекса не была снята блокировка. Одиночный процесс может также заблокировать самого себя. Если он вызывает функцию:
link("a/b/c", "a/b/c/d");
то в начале алгоритма он получает индекс для файла «c»; если бы ядро не снимало бы с индекса блокировку, процесс зашел бы в тупик, запросив индекс «c» при поиске файла «d». Если бы два процесса, или даже один процесс, не могли продолжать свое выполнение из-за взаимной блокировки (или самоблокировки), что в результате произошло бы в системе? Поскольку индексы являются теми ресурсами, которые предоставляются системой за конечное время, получение сигнала не может быть причиной возобновления процессом своей работы (глава 7). Следовательно, система не может выйти из тупика без перезагрузки. Если к файлам, заблокированным процессами, нет обращений со стороны других процессов, взаимная блокировка не затрагивает остальные процессы в системе. Однако, любые процессы, обратившиеся к этим файлам (или обратившиеся к другим файлам через заблокированный каталог), непременно зайдут в тупик. Таким образом, если заблокированы файлы «/bin» или «/usr/bin» (обычные хранилища команд) или файл «/bin/sh» (командный процессор shell), последствия для системы будут гибельными.