Архитектура операционной системы UNIX - Морис Бах

алгоритм umount

входная информация: имя специального файла, соответствующего демонтируемой файловой системе

выходная информация: отсутствует

{

 if (пользователь не является суперпользователем) return (ошибку);

 получить индекс специального файла (алгоритм namei);

 извлечь старший и младший номера демонтируемого устройства;

 получить в таблице монтирования запись для демонтируемой системы, исходя из старшего и младшего номеров;

 освободить индекс специального файла (алгоритм iput);

 удалить из таблицы областей записи с разделяемым текстом для файлов, принадлежащих файловой системе;

 /* глава 7ххх */

 скорректировать суперблок, индексы, выгрузить буферы на диск;

 if (какие-то файлы из файловой системы все еще используются) return (ошибку);

 получить из таблицы монтирования корневой индекс монтированной файловой системы;

 заблокировать индекс;

 освободить индекс (алгоритм iput);

 /* iget был при монтировании */

 запустить процедуру закрытия для специального устройства;

 сделать недействительными (отменить) в пуле буферы из демонтируемой файловой системы;

 получить из таблицы монтирования индекс точки монтирования;

 заблокировать индекс;

 очистить флаг, помечающий индекс как «точку монтирования»;

 освободить индекс (алгоритм iput);

 /* iget был при монтировании */

 освободить буфер, используемый под суперблок;

 освободить в таблице монтирования место, занятое ранее;

}

Рисунок 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 устраняет необходимость в связывании каталогов.

алгоритм link

входная информация:

 существующее имя файла

 новое имя файла

выходная информация: отсутствует

{

 получить индекс для существующего имени файла (алгоритм namei);

 if (у файла слишком много связей или производится связывание каталога без разрешения суперпользователя) {

  освободить индекс (алгоритм iput);

  return (ошибку);

 }

 увеличить значение счетчика связей в индексе;

 откорректировать дисковую копию индекса;

 снять блокировку с индекса;

 получить индекс родительского каталога для включения нового имени файла (алгоритм namei);

 if (файл с новым именем уже существует или существующий файл и новый файл находятся в разных файловых системах) {

  отменить корректировку, сделанную выше;

  return (ошибку);

 }

 создать запись в родительском каталоге для файла с новым именем;

 включить в нее новое имя и номер индекса существующего файла;

 освободить индекс родительского каталога (алгоритм iput);

 освободить индекс существующего файла (алгоритм iput);

}

Рисунок 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), последствия для системы будут гибельными.