пользователей дополнительных сведений. +------------------------------------------------------------+ | алгоритм mount | | входная информация: имя блочного специального файла | | имя каталога точки монтирования | | опции ("только для чтения") | | выходная информация: отсутствует | | { | | если (пользователь не является суперпользователем) | | возвратить (ошибку); | | получить индекс для блочного специального файла (алго- | | ритм namei); | | проверить допустимость значений параметров; | | получить индекс для имени каталога, где производится | | монтирование (алгоритм namei); | | если (индекс не является индексом каталога или счетчик | | ссылок имеет значение > 1) | | { | | освободить индексы (алгоритм iput); | | возвратить (ошибку); | | } | | найти свободное место в таблице монтирования; | | запустить процедуру открытия блочного устройства для | | данного драйвера; | | получить свободный буфер из буферного кеша; | | считать суперблок в свободный буфер; | | проинициализировать поля суперблока; | | получить корневой индекс монтируемой системы (алгоритм | | iget), сохранить его в таблице монтирования; | | сделать пометку в индексе каталога о том, что каталог | | является точкой монтирования; | | освободить индекс специального файла (алгоритм iput); | | снять блокировку с индекса каталога точки монтирования;| | } | +------------------------------------------------------------+ Рисунок 5.23. Алгоритм монтирования файловой системы 113 На Рисунке 5.23 показан алгоритм монтирования файловой системы. Ядро позволяет монтировать и демонтировать файловые системы только тем процессам, владельцем которых является суперпользователь. Предоставление возможности выполнять функции mount и umount всем пользователям привело бы к внесению с их стороны хаоса в работу файловой системы, как умышленному, так и явившему- ся результатом неосторожности. Суперпользователи могут разрушить систему только случайно. Ядро находит индекс специального файла, представляющего файловую систе- му, подлежащую монтированию, извлекает старший и младший номера, которые идентифицируют соответствующий дисковый раздел, и выбирает индекс каталога, в котором файловая система будет смонтирована. Счетчик ссылок в индексе ка- талога должен иметь значение, не превышающее 1 (и меньше 1 он не должен быть - почему?), в связи с наличием потенциально опасных побочных эффектов (см. упражнение 5.27). Затем ядро назначает свободное место в таблице монтирова- ния, помечает его для использования и присваивает значение полю номера уст- ройства в таблице. Вышеуказанные назначения производятся немедленно, пос- кольку вызывающий процесс может приостановиться, следуя процедуре открытия устройства или считывая суперблок файловой системы, а другой процесс тем временем попытался бы смонтировать файловую систему. Пометив для использова- ния запись в таблице монтирования, ядро не допускает использования в двух вызовах функции mount одной и той же записи таблицы. Запоминая номер устрой- ства с монтируемой системой, ядро может воспрепятствовать повторному монти- рованию одной и той же системы другими процессами, которое, будь оно допуще- но, могло бы привести к непредсказуемым последствиям (см. упражнение 5.26). Ядро вызывает процедуру открытия для блочного устройства, содержащего файловую систему, точно так же, как оно делает это при непосредственном отк- рытии блочного устройства (глава 10). Процедура открытия устройства обычно проверяет существование такого устройства, иногда производя инициализацию структур данных драйвера и посылая команды инициализации аппаратуре. Затем ядро выделяет из буферного пула свободный буфер (вариант алгоритма getblk) для хранения суперблока монтируемой файловой системы и считывает суперблок, используя один из вариантов алгоритма read. Ядро сохраняет указатель на ин- декс каталога, в котором монтируется система, давая возможность маршрутам поиска файловых имен, содержащих имя "..", пересекать точку монтирования, как мы увидим дальше. Оно находит корневой индекс монтируемой файловой сис- темы и запоминает указатель на индекс в таблице монтирования. С точки зрения пользователя, место (точка) монтирования и корень файловой системы логически эквивалентны, и ядро упрочивает эту эквивалентность благодаря их сосущество- ванию в одной записи таблицы монтирования. Процессы больше не могут обра- щаться к индексу каталога - точки монтирования. Ядро инициализирует поля в суперблоке файловой системы, очищая поля для списка свободных блоков и списка свободных индексов и устанавливая число свободных индексов в суперблоке равным 0. Целью инициализации (задания на- чальных значений полей) является сведение к минимуму опасности разрушить файловую систему, если монтирование осуществляется после аварийного заверше- ния работы системы. Если ядро заставить думать, что в суперблоке отсутствуют свободные индексы, то это приведет к запуску алгоритма ialloc, ведущего по- иск на диске свободных индексов. К сожалению, если список свободных дисковых блоков испорчен, ядро не исправляет этот список изнутри (см. раздел 5.17 о сопровождении файловой системы). Если пользователь монтирует файловую систе- му только для чтения, запрещая проведение всех операций записи в системе, ядро устанавливает в суперблоке соответствующий флаг. Наконец, ядро помечает индекс каталога как "точку монтирования", чтобы другие процессы позднее мог- ли ссылаться на нее. На Рисунке 5.24 представлен вид различных структур дан- ных по завершении выполнения функции mount. 114 5.14.1 Пересечение точек монтирования в маршрутах поиска имен файлов Давайте повторно рассмотрим поведение алгоритмов namei и iget в случаях, когда маршрут поиска файлов проходит через точку монтирования. Точку монти- рования можно пересечь двумя способами: из файловой системы, где производит- ся монтирование, в файловую систему, которая монтируется (в направлении от глобального корня к листу), и в обратном направлении. Эти способы иллюстри- рует следующая последовательность команд shell'а. Таблица индексов Таблица монтирования +------------------+ +--------------------+ +------------------+ | | | Индекс каталога, + - - + | | | где производится | | | | монтирование | | | | +-------+ | Помечен как "точ-|<---+ | |+->| Буфер | | ка монтирования" | || | || +-------+ | Счетчик ссылок =1| | | || +------------------+ |+ >+--------------------+| | | | | Суперблок ---++ +------------------+ +---+ Индекс точки монти-| | Индекс устройства| | рования | | Не используется | +---+- Корневой индекс | | Счетчик ссылок =0| | +--------------------+ +------------------+ | | | +------------------+<---+ | | | Индекс корня мон-| | | | тируемой файловой| | | | системы | | | | Счетчик ссылок =1| +--------------------+ +------------------+ +------------------+ Рисунок 5.24. Структуры данных после монтирования mount /dev/dsk1 /usr cd /usr/src/uts cd ../../.. По команде mount после выполнения некоторых логических проверок запуска- ется системная функция mount, которая монтирует файловую систему в дисковом разделе с именем "/dev/dsk1" под управлением каталога "/usr". Первая из ко- манд cd (сменить каталог) побуждает командный процессор shell вызвать сис- темную функцию chdir, выполняя которую, ядро анализирует имя пути поиска, пересекающего точку монтирования в "/usr". Вторая из команд cd приводит к тому, что ядро анализирует имя пути поиска и пересекает точку монтирования в третьей компоненте ".." имени. Для случая пересечения точки монтирования в направлении из файловой сис- темы, где производится монтирование, в файловую систему, которая монтирует- ся, рассмотрим модификацию алгоритма iget (Рисунок 5.25), которая идентична версии алгоритма, приведенной на Рисунке 4.3, почти во всем, за исключением того, что в данной модификации производится проверка, является ли индекс ин- дексом точки монтирования. Если индекс имеет соответствующую пометку, ядро соглашается, что это индекс точки монтирования. Оно обнаруживает в таблице монтирования запись с указанным индексом точки монтирования и запоминает но- мер устройства монтируемой файловой системы. Затем, используя номер устройс- тва и номер индекса корня, общего для всех файловых систем, ядро обращается к индексу корня 115 +------------------------------------------------------------+ | алгоритм iget | | входная информация: номер индекса в файловой системе | | выходная информация: заблокированный индекс | | { | | выполнить | | { | | если (индекс в индексном кеше) | | { | | если (индекс заблокирован) | | { | | приостановиться (до освобождения индекса); | | продолжить; /* цикл с условием продолжения */ | | } | | /* специальная обработка для точек монтирования */ | | если (индекс является индексом точки монтирования) | | { | | найти запись в таблице монтирования для точки мон- | | тирования; | | получить новый номер файловой системы из таблицы | | монтирования; | | использовать номер индекса корня для просмотра; | | продолжить; /* продолжение цикла */ | | } | | если (индекс в списке свободных индексов) | | убрать из списка свободных индексов; | | увеличить счетчик ссылок для индекса; | | возвратить (индекс); | | } | | | | /* индекс отсутствует в индексном кеше */ | | убрать новый индекс из списка свободных индексов; | | сбросить номер индекса и файловой системы; | | убрать индекс из старой хеш-очереди, поместить в новую;| | считать индекс с диска (алгоритм bread); | | инициализировать индекс (например, установив счетчик | | ссылок в 1); | | возвратить (индекс); | | } | | } | +------------------------------------------------------------+ Рисунок 5.25. Модификация алгоритма получения доступа к ин- дексу монтируемого устройства и возвращает при выходе из функции этот индекс. В первом примере смены каталога ядро обращается к индексу каталога "/usr" из файловой системы, в которой производится монтирование, обнаруживает, что этот индекс имеет пометку "точка монтирования", находит в таблице монтирова- ния индекс корня монтируемой файловой системы и обращается к этому индексу. Для второго случая пересечения точки монтирования в направлении из фай- ловой системы, которая монтируется, в файловую систему, где выполняется мон- тирование, рассмотрим модификацию алгоритма namei (Рисунок 5.26). Она похожа на версию алгоритма, приведенную на Рисунке 4.11. Однако, после обнаружения в каталоге номера индекса для данной компоненты пути поиска ядро проверяет, не указывает ли номер индекса на то, что это корневой индекс файловой систе- мы. Если это так и если текущий рабочий индекс так же является корневым, а 116 +------------------------------------------------------------+ | алгоритм namei /* превращение имени пути поиска в индекс */| | входная информация: имя пути поиска | | выходная информация: заблокированный индекс | | { | | если (путь поиска берет начало с корня) | | рабочий индекс = индексу корня (алгоритм iget); | | в противном случае | | рабочий индекс = индексу текущего каталога | | (алгоритм iget); | | | | выполнить (пока путь поиска не кончился) | | { | | считать следующую компоненту имени пути поиска; | | проверить соответствие рабочего индекса каталогу | | и права доступа; | | если (рабочий индекс соответствует корню и компо- | | нента имени "..") | | продолжить; /* цикл с условием продолжения */| | поиск компоненты: | | считать каталог (рабочий индекс), повторяя алго- | | ритмы bmap, bread и brelse; | | если (компонента соответствует записи в каталоге | | (рабочем индексе)) | | { | | получить номер индекса для совпавшей компонен-| | ты; | | если (найденный индекс является индексом кор- | | ня и рабочий индекс является индексом корня | | и имя компоненты "..") | | { | | /* пересечение точки монтирования */ | | получить запись в таблице монтирования для | | рабочего индекса; | | освободить рабочий индекс (алгоритм iput); | | рабочий индекс = индексу точки монтирования;| | заблокировать индекс точки монтирования; | | увеличить значение счетчика ссылок на рабо- | | чий индекс; | | перейти к поиску компоненты (для ".."); | | } | | освободить рабочий индекс (алгоритм iput); | | рабочий индекс = индексу с новым номером | | (алгоритм iget); | | } | | в противном случае /* компонента отсутствует в | | каталоге */ | | возвратить (нет индекса); | | } | | возвратить (рабочий индекс); | | } | +------------------------------------------------------------+ Рисунок 5.26. Модификация алгоритма синтаксического анализа имени файла компонента пути поиска, в свою очередь, имеет имя "..", ядро идентифицирует индекс как точку монтирования. Оно находит в таблице монтирования запись, 117 номер устройства в которой совпадает с номером устройства для последнего из найденных индексов, получает индекс для каталога, в котором производится монтирование, и продолжает поиск компоненты с именем "..", используя только что полученный индекс в качестве рабочего. В корне файловой системы, тем не менее, корневым каталогом является "..". В вышеприведенном примере (cd "../../..") предполагается, что в начале процесс имеет текущий каталог с именем "/usr/src/uts". Когда имя пути поиска подвергается анализу в алгоритме namei, начальным рабочим индексом является индекс текущего каталога. Ядро меняет текущий рабочий индекс на индекс ката- лога с именем "/usr/src" в результате расшифровки первой компоненты ".." в имени пути поиска. Затем ядро анализирует вторую компоненту ".." в имени пу- ти поиска, находит корневой индекс смонтированной (перед этим) файловой сис- темы - индекс каталога "usr" - и делает его рабочим индексом при анализе имени с помощью алгоритма namei. Наконец, оно расшифровывает третью компо- ненту ".." в имени пути поиска. Ядро обнаруживает, что номер индекса для ".." совпадает с номером корневого индекса, рабочим индексом является корне- вой индекс, а ".." является текущей компонентой имени пути поиска. Ядро на- ходит запись в таблице монтирования, соответствующую точке монтирования "usr", освобождает текущий рабочий индекс (корень файловой системы, смонти- рованной в каталоге "usr") и назначает индекс точки монтирования (каталога "usr" в корневой файловой системе) в качестве нового рабочего индекса. Затем оно просматривает записи в каталоге точки монтирования "/usr" в поисках име- ни ".." и находит номер индекса для корня файловой системы ("/"). После это- го системная функция chdir завершается как обычно, вызывающий процесс не об- ращает внимания на тот факт, что он пересек точку монтирования. 5.14.2 Демонтирование файловой системы Синтаксис вызова системной функции umount: umount(special filename); где special filename указывает демонтируемую файловую систему. При демонти- ровании файловой системы (Рисунок 5.27) ядро обращается к индексу демонтиру- емого устройства, восстанавливает номер устройства для специального файла, освобождает индекс (алгоритм iput) и находит в таблице монтирования запись с номером устройства, равным номеру устройства для специального файла. Прежде чем ядро действительно демонтирует файловую систему, оно должно удостове- риться в том, что в системе не осталось используемых файлов, для этого ядро просматривает таблицу индексов в поисках всех файлов, чей номер устройства совпадает с номером демонтируемой системы. Активным файлам соответствует по- ложительное значение счетчика ссылок и в их число входят текущий каталог процесса, файлы с разделяемым текстом, которые исполняются в текущий момент (глава 7), и открытые когда-то файлы, которые потом не были закрыты. Если какие-нибудь файлы из файловой системы активны, функция umount завершается неудачно: если бы она прошла успешно, активные файлы сделались бы недоступ- ными. Буферный пул все еще содержит блоки с "отложенной записью", не перепи- санные на диск, поэтому ядро "вымывает" их из буферного пула. Ядро удаляет записи с разделяемым текстом, которые находятся в таблице областей, но не являются действующими (подробности в главе 7), записывает на диск все недав- но скорректированные суперблоки и корректирует дисковые копии всех индексов, которые требуют этого. Казалось, было бы достаточно откорректировать диско- вые блоки, суперблок и индексы только для демонтируемой файловой системы, однако в целях сохранения преемственности изменений ядро выполняет аналогичные действия для всей системы в целом. Затем ядро ос- вобождает корневой индекс монтированной файловой системы, удерживаемый с мо- мента первого обращения к нему во время выполнения функции mount, и запуска- 118 +------------------------------------------------------------+ | алгоритм umount | | входная информация: имя специального файла, соответствую- | | щего демонтируемой файловой системе | | выходная информация: отсутствует | | { | | если (пользователь не является суперпользователем) | | возвратить (ошибку); | | получить индекс специального файла (алгоритм namei); | | извлечь старший и младший номера демонтируемого устрой-| | ства; | | получить в таблице монтирования запись для демонтируе- | | мой системы, исходя из старшего и младшего номеров; | | освободить индекс специального файла (алгоритм iput); | | удалить из таблицы областей записи с разделяемым текс- | | том для файлов, принадлежащих файловой | | системе; /* глава 7ххх */ | | скорректировать суперблок, индексы, выгрузить буферы | | на диск; | | если (какие-то файлы из файловой системы все еще ис- | | пользуются) | | возвратить (ошибку); | | получить из таблицы монтирования корневой индекс монти-| | рованной файловой системы; | | заблокировать индекс; | | освободить индекс (алгоритм iput); /* iget был при | | монтировании */ | | запустить процедуру закрытия для специального устрой- | | ства; | | сделать недействительными (отменить) в пуле буферы из | | демонтируемой файловой системы; | | получить из таблицы монтирования индекс точки монтиро- | | вания; | | заблокировать индекс; | | очистить флаг, помечающий индекс как "точку монтирова- | | ния"; | | освободить индекс (алгоритм iput); /* iget был при | | монтировании */ | | освободить буфер, используемый под суперблок; | | освободить в таблице монтирования место, занятое ранее;| | } | +------------------------------------------------------------+ Рисунок 5.27. Алгоритм демонтирования файловой системы ет из драйвера процедуру закрытия устройства, содержащего файловую систему. Впоследствии ядро просматривает буферы в буферном кеше и делает недействи- тельными те из них, в которых находятся блоки демонтируемой файловой систе- мы; в хранении информации из этих блоков в кеше больше нет необходимости. Делая буферы недействительными, ядро вставляет их в начало списка свободных буферов, в то время как блоки с актуальной информацией остаются в буферном кеше. Ядро сбрасывает в индексе системы, где производилось монтирование, флаг "точки монтирования", установленный функцией mount, и освобождает ин- декс. Пометив запись в таблице монтирования свободной для общего использова- ния, функция umount завершает работу. 119 / | usr +------------+-------------+ | | src include | +----+----+ uts sys realfile.h | - - sys -------------------- - +-------+-------+ - inode.h testfile.h ------------------ Рисунок 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 показан алгоритм функции link. Сначала ядро, используя алгоритм namei, определяет местонахождение индекса исходного файла, увеличи- вает значение счетчика связей в индексе, корректирует дисковую копию индекса (для обеспечения согласованности) и снимает с индекса блокировку. Затем ядро ищет файл с новым именем; если он существует, функция link завершается неу- дачно и ядро восстанавливает прежнее значение счетчика связей, измененное ранее. В противном случае ядро находит в родительском каталоге свободную за- пись для файла с новым именем, записывает в нее новое имя и номер индекса исходного файла и освобождает индекс родительского каталога, используя алго- 120 +------------------------------------------------------------+ | алгоритм link | | входная информация: существующее имя файла | | новое имя файла | | выходная информация: отсутствует | | { | | получить индекс для существующего имени файла (алгоритм | | namei); | | если (у файла слишком много связей или производится | | связывание каталога без разрешения суперпользователя) | | { | | освободить индекс (алгоритм iput); | | возвратить (ошибку); | | } | | увеличить значение счетчика связей в индексе; | | откорректировать дисковую копию индекса; | | снять блокировку с индекса; | | получить индекс родительского каталога для включения но-| | вого имени файла (алгоритм namei); | | если (файл с новым именем уже существует или существую- | | щий файл и новый файл находятся в разных файловых сис- | | темах) | | { | | отменить корректировку, сделанную выше; | | возвратить (ошибку); | | } | | создать запись в родительском каталоге для файла с но- | | вым именем: | | включить в нее новое имя и номер индекса существую- | | щего файла; | | освободить индекс родительского каталога (алгоритм | | iput); | | освободить индекс существующего файла (алгоритм iput); | | } | +------------------------------------------------------------+ Рисунок 5.29. Алгоритм связывания файлов ритм iput. Поскольку файл с новым именем ранее не существовал, освобождать еще какой-нибудь индекс не нужно. Ядро, освобождая индекс исходного файла, делает заключение: счетчик связей в индексе имеет значение, на 1 большее, чем то значение, которое счетчик имел перед вызовом функции, и обращение к файлу теперь может производиться по еще одному имени в файловой системе. Счетчик связей хранит количество записей в каталогах, которые (записи) ука- зывают на файл, и тем самым отличается от счетчика ссылок в индексе. Если по завершении выполнения функции link к файлу нет обращений со стороны других процессов, счетчик ссылок в индексе принимает значение, равное 0, а счетчик связей - значение, большее или равное 2. Например, выполняя функцию, вызванную как: link("source","/dir/target"); ядро обнаруживает индекс для файла "source", увеличивает в нем значение счетчика связей, запоминает номер индекса, скажем 74, и снимает с индекса блокировку. Ядро также находит индекс каталога "dir", являющегося родитель- ским каталогом для файла "target", ищет свободное место в каталоге "dir" и записывает в него имя файла "target" и номер индекса 74. По окончании этих действий оно освобождает индекс файла "source" по алгоритму iput. Если зна- чение счетчика связей файла "source" раньше было равно 1, то теперь оно рав- 121 но 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), последствия для системы будут гибель- ными. 5.16 UNLINК Системная функция unlink удаляет из каталога точку входа для файла. Син- таксис вызова функции unlink: unlink(pathname); где pathname указывает имя файла, удаляемое из иерархии каталогов. Если про- цесс разрывает данную связь файла с каталогом при помощи функции unlink, по указанному в вызове функции имени файл не будет доступен, пока в каталоге не 122 Процесс A Процесс B +------------------------------------------------------------- | - Пытается получить индекс | - для файла "e" | - ПРИОСТАНОВ - индекс файла | - "e" заблокирован | Получает индекс для "a" - | Освобождает индекс "a" - | Получает индекс для "b" - | Освобождает индекс "b" - | Получает индекс для "c" - | Освобождает индекс "c" - | Получает индекс для "d" - | - | Пытается получить индекс - | для "e" - | ПРИОСТАНОВ - индекс файла - | "e" заблокирован - | - - | +-----------------------------------------------+ | | Возобновление выполнения - индекс файла "e" | | | разблокирован | | +-----------------------------------------------+ | - Получает индекс для "e" | - Освобождает индекс "e" | - Получает индекс для "f" | - Получает индекс для "a" | - Освобождает индекс "a" | - - | - - | - Пытается получить индекс | - для файла "d" | - ПРИОСТАНОВ - индекс файла | - "d" заблокирован | - процессом A | - | Получает индекс для "e" | Освобождает индекс "e" | Пытается получить индекс | для "f" | ПРИОСТАНОВ - индекс файла | "f" заблокирован | процессом B | +-------------------------------+ | | Тупик (взаимная блокировка) | v +-------------------------------+ Время Рисунок 5.30. Взаимная блокировка процессов при выполнении функции link создана еще одна запись с этим именем. Например, при выполнении следующего фрагмента программы: unlink("myfile"); fd = open("myfile",O_RDONLY); функция open завершится неудачно, поскольку к моменту ее выполнения в теку- щем каталоге больше не будет файла с именем myfile. Если удаляемое имя явля- 123 ется последней связью файла с каталогом, ядро в итоге освобождает все инфор- мационные блоки файла. Однако, если у файла было несколько связей, он оста- ется все еще доступным под другими именами. На Рисунке 5.31 представлен алгоритм функции unlink. Сначала для поиска файла с удаляемой связью ядро использует модификацию алгоритма namei, кото- рая вместо индекса файла возвращает индекс родительского каталога. Ядро об- ращается к индексу файла в памяти, используя алгоритм iget. (Особый случай, связанный с удалением имени файла ".", будет рассмотрен в упражнении). После проверки отсутствия ошибок и (для исполняемых файлов) удаления из таблицы областей записей с неактивным разделяемым текстом (глава 7) ядро стирает имя файла из родительского каталога: сделать значение номера индекса равным 0 достаточно для очистки места, занимаемого именем файла в каталоге. Затем яд- ро производит синхронную запись каталога на диск, гарантируя тем самым, что под своим прежним именем файл уже не будет доступен, уменьшает значение счетчика связей и с помощью алгоритма iput освобождает в памяти индексы ро- дительского каталога и файла с удаляемой связью. При освобождении в памяти по алгоритму iput индекса файла с удаляемой связью, если значения счетчика ссылок и счетчика связей становятся равными 0, ядро забирает у файла обратно дисковые блоки, которые он занимал. На этот индекс больше не указывает ни одно из файловых имен и индекс неактивен. Для +------------------------------------------------------------+ | алгоритм unlink | | входная информация: имя файла | | выходная информация: отсутствует | | { | | получить родительский индекс для файла с удаляемой | | связью (алгоритм namei); | | /* если в качестве файла выступает текущий каталог... */| | если (последней компонентой имени файла является ".") | | увеличить значение счетчика ссылок в индексе; | | в противном случае | | получить индекс для файла с удаляемой связью (алго-| | ритм iget); | | если (файл является каталогом, но пользователь не явля- | | ется суперпользователем) | | { | | освободить индексы (алгоритм iput); | | возвратить (ошибку); | | } | | если (файл имеет разделяемый текст и текущее значение | | счетчика связей равно 1) | | удалить записи из таблицы областей; | | в родительском каталоге: обнулить номер индекса для уда-| | ляемой связи; | | освободить индекс родительского каталога (алгоритм | | iput); | | уменьшить число связей файла; | | освободить индекс файла (алгоритм iput); | | /* iput проверяет, равно ли число связей 0, если | | * да, | | * освобождает блоки файла (алгоритм free) и | | * освобождает индекс (алгоритм ifree); | | */ | | } | +------------------------------------------------------------+ Рисунок 5.31. Алгоритм удаления связи файла с каталогом 124 того, чтобы забрать дисковые блоки, ядро в цикле просматривает таблицу со- держимого индекса, освобождая все блоки прямой адресации немедленно (в соот- ветствии с алгоритмом free). Что касается блоков косвенной адресации, ядро освобождает все блоки, появляющиеся на различных уровнях косвенности, рекур- сивно, причем в первую очередь освобождаются блоки с меньшим уровнем. Оно обнуляет номера блоков в таблице содержимого индекса и устанавливает размер файла в индексе равным 0. Затем ядро очищает в индексе поле типа файла, ука- зывая тем самым, что индекс свободен, и освобождает индекс по алгоритму ifree. Ядро делает необходимую коррекцию на диске, так как дисковая копия индекса все еще указывает на то, что индекс используется; теперь индекс сво- боден для назначения другим файлам. 5.16.1 Целостность файловой системы Ядро посылает свои записи на диск для того, чтобы свести к минимуму опасность искажения файловой системы в случае системного сбоя. Например, когда ядро удаляет имя файла из родительского каталога, оно синхронно пере- писывает каталог на диск - перед тем, как уничтожить содержимое файла и ос- вободить его индекс. Если система дала сбой до того, как произошло удаление содержимого файла, ущерб файловой системе будет нанесен минимальный: один из индексов будет иметь число связей, на 1 превышающее число записей в катало- ге, которые ссылаются на этот индекс, но все остальные имена путей поиска файла останутся допустимыми. Если запись на диск не была сделана синхронно, точка входа в каталог на диске после системного сбоя может указывать на сво- бодный (или переназначенный) индекс. Таким образом, число записей в каталоге на диске, которые ссылаются на индекс, превысило бы значение счетчика ссылок в индексе. В частности, если имя файла было именем последней связи файла, это имя указывало бы на неназначенный индекс. Не вызывает сомнения, что в первом случае ущерб, наносимый системе, менее серьезен и легко устраним (см. раздел 5.18). Предположим, например, что у файла есть две связи с именами "a" и "b", одна из которых - "a" - разрывается процессом с помощью функции unlink. Если ядро записывает на диске результаты всех своих действий, то оно, очищая точ- ку входа в каталог для файла "a", делает то же самое на диске. Если система дала сбой после завершения записи результатов на диск, число связей у файла "b" будет равно 2, но файл "a" уже не будет существовать, поскольку прежняя запись о нем была очищена перед сбоем системы. Файл "b", таким образом, бу- дет иметь лишнюю связь, но после перезагрузки число связей переустановится и система будет работать надлежащим образом. Теперь предположим, что ядро записывало на диск результаты своих дейст- вий в обратном порядке и система дала сбой: то есть, ядро уменьшило значение счетчика связей для файла "b", сделав его равным 1, записало индекс на диск и дало сбой перед тем, как очистить в каталоге точку входа для файла "a". После перезагрузки системы записи о файлах "a" и "b" в соответствующих ката- логах будут существовать, но счетчик связей у того файла, на который они указывают, будет иметь значение 1. Если затем процесс запустит функцию unlink для файла "a", значение счетчика связей станет равным 0, несмотря на то, что файл "b" ссылается на тот же индекс. Если позднее ядро переназначит индекс в результате выполнения функции creat, счетчик связей для нового фай- ла будет иметь значение, равное 1, но на файл будут ссылаться два имени пути поиска. Система не может выправить ситуацию, не прибегая к помощи программ сопровождения (fsck, описанной в разделе 5.18), обращающихся к файловой сис- теме через блочный или строковый интерфейс. Для того, чтобы свести к минимуму опасность искажения файловой системы в случае системного сбоя, ядро освобождает индексы и дисковые блоки также в особом порядке. При удалении содержимого файла и очистке его индекса можно сначала освободить блоки, содержащие данные файла, а можно освободить индекс 125 и заново переписать его. Результат в обоих случаях, как правило, одинаковый, однако, если где-то в середине произойдет системный сбой, они будут разли- чаться. Предположим, что ядро сначала освободило дисковые блоки, принадле- жавшие файлу, и дало сбой. После перезагрузки системы индекс все еще содер- жит ссылки на дисковые блоки, занимаемые файлом прежде и ныне не хранящие относящуюся к файлу информацию. Ядру файл показался бы вполне удовлетвори- тельным, но пользователь при обращении к файлу заметит искажение данных. Эти дисковые блоки к тому же могут быть переназначены другим файлам. Чтобы очис- тить файловую систему программой fsck, потребовались бы большие усилия. Од- нако, если система сначала переписала индекс на диск, а потом дала сбой, пользователь не заметит каких-либо искажений в файловой системе после пере- загрузки. Информационные блоки, ранее принадлежавшие файлу, станут недоступ- ны для системы, но каких-нибудь явных изменений при этом пользователи не увидят. Программе fsck так же было бы проще забрать назад освободившиеся после удаления связи дисковые блоки, нежели производить очистку, необходимую в первом из рассматриваемых случаев. 5.16.2 Поводы для конкуренции Поводов для конкуренции при выполнении системной функции unlink очень много, особенно при удалении имен каталогов. Команда rmdir удаляет каталог, убедившись предварительно в том, что в каталоге отсутствуют файлы (она счи- тывает каталог и проверяет значения индексов во всех записях каталога на ра- венство нулю). Но так как команда rmdir запускается на пользовательском уровне, действия по проверке содержимого каталога и удаления каталога выпол- няются не так уж просто; система должна переключать контекст между выполне- нием функций read и unlink. Однако, после того, как команда rmdir обнаружи- ла, что каталог пуст, другой процесс может предпринять попытку создать файл в каталоге функцией creat. Избежать этого пользователи могут только путем использования механизма захвата файла и записи. Тем не менее, раз процесс приступил к выполнению функции unlink, никакой другой процесс не может обра- титься к файлу с удаляемой связью, поскольку индексы родительского каталога и файла заблокированы. Обратимся еще раз к алгоритму функции link и посмотрим, каким образом система снимает с индекса блокировку до завершения выполнения функции. Если бы другой процесс удалил связь файла пока его индекс свободен, он бы тем са- мым только уменьшил значение счетчика связей; так как значение счетчика свя- зей было увеличено перед удалением связи, это значение останется положитель- ным. Следовательно, файл не может быть удален и система работает надежно. Эта ситуация аналогична той, когда функция unlink вызывается сразу после за- вершения выполнения функции link. Другой повод для конкуренции имеет место в том случае, когда один про- цесс преобразует имя пути поиска файла в индекс файла по алгоритму namei, а другой процесс удаляет каталог, имя которого входит в путь поиска. Допустим, процесс A делает разбор имени "a/ b/c/d" и приостанавливается во время полу- чения индекса для файла "c". Он может приостановиться при попытке заблокиро- вать индекс или при попытке обратиться к дисковому блоку, где этот индекс хранится (см. алгоритмы iget и bread). Если процессу B нужно удлить связь для каталога с именем "c", он может приостановиться по той же самой причине, что и процесс A. Пусть ядро впоследствии решит возобновить процесс B раньше процесса A. Прежде чем процесс A продолжит свое выполнение, процесс B завер- шится, удалив связь каталога "c" и его содержимое по этой связи. Позднее, процесс A попытается обратиться к несуществующему индексу, который уже был удален. Алгоритм namei, проверяющий в первую очередь неравенство значения счетчика связей нулю, сообщит об ошибке. Такой проверки, однако, не всегда достаточно, поскольку можно предполо- жить, что какой-нибудь другой процесс создаст в любом месте файловой системы новый каталог и получит тот индекс, который ранее использовался для "c". 126 Процесс A будет заблуждаться, думая, что он обратился к нужному индексу (см. Рисунок 5.32). Как бы то ни было, система сохраняет свою целостность; самое худшее, что может произойти, это обращение не к тому файлу - с возможным на- Процесс A Процесс B Процесс C +------------------------------------------------------------ | - Удаляется связь фай- - | - ла с именем "с" - | - - | - Обнаруживает, что - | - индекс файла "c" - | - заблокирован - | - Приостанавливает - | - выполнение - | - - - | Просматривает ка- - - | талог "b" в поис- - - | ках имени "c" - - | Получает номер ин- - - | декса для "c" - - | Обнаруживает, что - - | индекс файла "c" - - | заблокирован - - | Приостанавливает - - | выполнение - - | - - - | - Возобновляет выпол- - | - нение, индекс "c" - | - свободен - | - Удаляет связь с име- - | - нем "c", прежний ин- - | - декс освобождается, - | - если число связей =0 - | - - - | - - Назначает индекс | - - новому файлу "n" | - - Случайно назнача- | - - ет ему индекс, ра- | - - нее принадлежавший | - - "c" | - - | - - В конечном итоге | - - снимает блокировку | - - с индекса "n" | - - | Возобновляет выпол- - | нение, прежний ин- - | декс "c" (теперь - | "n") свободен - | Получает индекс "n" - | Просматривает ка- - | талог "n" в поис- - | ках имени "d" - v Время Рисунок 5.32. Соперничество процессов за индекс при выполне- нии функции unlink 127 +------------------------------------------------------------+ | #include | | #include | | #include | | | | main(argc,argv) | | int argc; | | char *argv[]; | | { | | int fd; | | char buf[1024]; | | struct stat statbuf; | | | | if (argc != 2) /* нужен параметр */ | | exit(); | | fd = open(argv[1],O_RDONLY); | | if (fd == -1) /* open завершилась | | неудачно */ | | exit(); | | if (unlink(argv[1]) == -1) /* удалить связь с только | | что открытым файлом */ | | exit(); | | if (stat(argv[1],&statbuf) == -1) /* узнать состоя- | | ние файла по имени */ | | printf("stat %s завершилась неудачно\n",argv[1]);| | /* как и следовало бы */ | | else | | printf("stat %s завершилась успешно!\n",argv[1]);| | if (fstat(fd,&statbuf) == -1) /* узнать состояние | | файла по идентификатору */ | | printf("fstat %s сработала неудачно!\n",argv[1]);| | else | | printf("fstat %s завершилась успешно\n",argv[1]);| | /* как и следовало бы */ | | while (read(fd,buf,sizeof(buf)) > 0) /* чтение откры- | | того файла с удаленной связью */ | | printf("%1024s",buf); /* вывод на печать поля | | размером 1 Кбайт */ | | } | +------------------------------------------------------------+ Рисунок 5.33. Удаление связи с открытым файлом рушением защиты - но соперничества такого рода на практике довольно редки. Процесс может удалить связь файла в то время, как другому процессу нуж- но, чтобы файл оставался открытым. (Даже процесс, удаляющий связь, может быть процессом, выполнившим это открытие). Поскольку ядро снимает с индекса блокировку по окончании выполнения функции open, функция unlink завершится успешно. Ядро будет выполнять алгоритм unlink точно так же, как если бы файл не был открыт, и удалит из каталога запись о файле. Теперь по имени удален- ной связи к файлу не сможет обратиться никакой другой процесс. Однако, так как системная функция open увеличила значение счетчика ссылок в индексе, яд- ро не очищает содержимое файла при выполнении алгоритма iput перед заверше- нием функции unlink. Поэтому процесс, открывший файл, может производить над файлом все обычные действия по его дескриптору, включая чтение из файла и запись в файл. Но когда процесс закрывает файл, значение счетчика ссылок в алгоритме iput становится равным 0, и ядро очищает содержимое файла. Короче говоря, процесс, открывший файл, продолжает работу так, как если бы функция 128 unlink не выполнялась, а unlink, в свою очередь, работает так, как если бы файл не был открыт. Другие системные функции также могут продолжать выпол- няться в процессе, открывшем файл. В приведенном на Рисунке 5.33 примере процесс открывает файл, указанный в качестве параметра, и затем удаляет связь только что открытого файла. Фун- кция stat завершится неудачно, поскольку первоначальное имя после unlink больше не указывает на файл (предпо- лагается, что тем временем никакой другой процесс не создал файл с тем же именем), но функция fstat завершится успешно, так как она выбирает индекс по дескриптору файла. Процесс выполняет цикл, считывая на каждом шаге по 1024 байта и пересылая файл в стандартный вывод. Когда при чтении будет обнаружен конец файла, процесс завершает работу: после завершения процесса файл перес- тает существовать. Процессы часто создают временные файлы и сразу же удаляют связь с ними; они могут продолжать ввод-вывод в эти файлы, но имена файлов больше не появляются в иерархии каталогов. Если процесс по какой-либо причи- не завершается аварийно, он не оставляет от временных файлов никакого следа. 5.17 АБСТРАКТНЫЕ ОБРАЩЕНИЯ К ФАЙЛОВЫМ СИСТЕМАМ Уайнбергером было введено понятие "тип файловой системы" для объяснения механизма работы принадлежавшей ему сетевой файловой системы (см. краткое описание этого механизма в [Killian 84]) и в позднейшей версии системы V поддерживаются основополагающие принципы его схемы. Наличие типа файловой системы дает ядру возможность поддерживать одновременно множество файловых систем, таких как сетевые файловые системы (глава 13) или даже файловые сис- темы из других операционных систем. Процессы пользуются для обращения к фай- лам обычными функциями системы UNIX, а ядро устанавливает соответствие между общим набором файловых операций и операциями, специфичными для каждого типа файловой системы. Операции файловой Общие индексы Индекс файловой системы системы версии V +---------------+ +------+ +-------+ Версия V | open | +-----+- -+-------->| | | close | | +------+ +-------+ | read | | +---+- -+---+ | | | write |<---+ | +------+ | +-------+ | - |<-----|---+- -+---|---->| | | - | | +------+ | +-------+ | - | | | | | | - | | - | | +------+ | | - | +---------------+ | | | | | - | Удаленная | ropen | | +------+ | +-------+ система | rclose | | | - | | | rread | | | - | | Индекс удален- | rwrite |<-----+ | - | | ной системы | - | | - | | +-------+ | - | | - | | | | | - | | - | | +-------+ | - | | - | +---->| | +---------------+ | - | +-------+ | - | | - | | | | - | | - | +-------+ | - | | - | | | | - | | - | +-------+ | - | | - | | - | +---------------+ +------+ +-------+ Рисунок 5.34. Индексы для файловых систем различных типов 129 Индекс выступает интерфейсом между абстрактной файловой системой и от- дельной файловой системой. Общая копия индекса в памяти содержит информацию, не зависящую от отдельной файловой системы, а также указатель на частный ин- декс файловой системы, который уже содержит информацию, специфичную для нее. Частный индекс файловой системы содержит такую информацию, как права доступа и расположение блоков, а общий индекс содержит номер устройства, номер ин- декса на диске, тип файла, размер, информацию о владельце и счетчик ссылок. Другая частная информация, описывающая отдельную файловую систему, содержит- ся в суперблоке и структуре каталогов. На Рисунке 5.34 изображены таблица общих индексов в памяти и две таблицы частных индексов отдельных файловых систем, одна для структур файловой системы версии V, а другая для индекса удаленной (сетевой) системы. Предполагается, что последний индекс содержит достаточно информации для того, чтобы идентифицировать файл, находящийся в удаленной системе. У файловой системы может отсутствовать структура, подоб- ная индексу; но исходный текст программ отдельной файловой системы позволяет создать объектный код, удовлетворяющий семантическим требованиям файловой системы UNIX и назначающий свой "индекс", который соответствует общему ин- дексу, назначаемому ядром. Файловая система каждого типа имеет некую структуру, в которой хранятся адреса функций, реализующих абстрактные действия. Когда ядру нужно обратить- ся к файлу, оно вызывает косвенную функцию в зависимости от типа файловой системы и абстрактного действия (см. Рисунок 5.34). Примерами абстрактных действий являются: открытие и закрытие файла, чтение и запись данных, возв- ращение индекса для компоненты имени файла (подобно namei и iget), освобож- дение индекса (подобно iput), коррекция индекса, проверка прав доступа, ус- тановка атрибутов файла (прав доступа к нему), а также монтирование и демон- тирование файловых систем. В главе 13 будет проиллюстрировано использование системных абстракций при рассмотрении распределенной файловой системы. 5.18 СОПРОВОЖДЕНИЕ ФАЙЛОВОЙ СИСТЕМЫ Ядро поддерживает целостность системы в своей обычной работе. Тем не ме- нее, такие чрезвычайные обстоятельства, как отказ питания, могут привести к фатальному сбою системы, в результате которого содержимое системы утрачивает свою согласованность: большинство данных в файловой системе доступно для ис- пользования, но некоторая несогласованность между ними имеет место. Команда fsck проверяет согласованность данных и в случае необходимости вносит в фай- ловую систему исправления. Она обращается к файловой системе через блочный или строковый интерфейс (глава 10) в обход традиционных методов доступа к файлам. В этом разделе рассматриваются некоторые примеры противоречивости данных, которая обнаруживается командой fsck. Дисковый блок может принадлежать более чем одному индексу или списку свободных блоков. Когда файловая система открывается в первый раз, все дис- ковые блоки находятся в списке свободных блоков. Когда дисковый блок выбира- ется для использования, ядро удаляет его номер из списка свободных блоков и назначает блок индексу. Ядро не может переназначить дисковый блок другому индексу до тех пор, пока блок не будет возвращен в список свободных блоков. Таким образом, дисковый блок может либо находиться в списке свободных бло- ков, либо быть назначенным одному из индексов. Рассмотрим различные ситуа- ции, могущие иметь место при освобождении ядром дискового блока, принадле- жавшего файлу, с возвращением номера блока в суперблок, находящийся в памя- ти, и при выделении дискового блока новому файлу. Если ядро записывало на диск индекс и блоки нового файла, но перед внесением изменений в индекс прежнего файла на диске произошел сбой, оба индекса будут адресовать к одно- 130 му и тому же номеру дискового блока. Подобным же образом, если ядро перепи- сывало на диск суперблок и его списки свободных ресурсов и перед переписью старого индекса случился сбой, дисковый блок появится одновременно и в спис- ке свободных блоков, и в старом индексе. Если блок отсутствует как в списке свободных блоков, так и в файле, фай- ловая система является несогласованной, ибо, как уже говорилось выше, все блоки обязаны где-нибудь присутствовать. Такая ситуация могла бы произойти, если бы блок был удален из файла и помещен в список свободных блоков в су- перблоке. Если производилась запись прежнего файла на диск и система дала сбой перед записью суперблока, блок будет отсутствовать во всех списках, хранящихся на диске. Индекс может иметь счетчик связей с ненулевым значением при том, что его номер отсутствует во всех каталогах файловой системы. Все файлы, за исключе- нием каналов (непоименованных), должны присутствовать в древовидной структу- ре файловой системы. Если система дала сбой после создания канала или обыч- ного файла, но перед созданием соответствующей этому каналу или файлу точки входа в каталог, индекс будет иметь в поле счетчика связей установленное значение, пусть даже он явно не присутствует в файловой системе. Еще одна проблема может возникнуть, если с помощью функции unlink была удалена связь каталога без проверки удаления из каталога всех содержащихся в нем связей с отдельными файлами. Если формат индекса неверен (например, если значение поля типа файла не определено), значит где-то имеется ошибка. Это может произойти, если адми- нистратор смонтировал файловую систему, которая отформатирована неправильно. Ядро обращается к тем дисковым блокам, которые, как кажется ядру, содержат индексы, но в действительности оказывается, что они содержат данные. Если номер индекса присутствует в записи каталога, но сам индекс свобо- ден, файловая система является несогласованной, поскольку номер индекса в записи каталога должен быть номером назначенного индекса. Это могло бы прои- зойти, если бы ядро, создавая новый файл и записывая на диск новую точку входа в каталог, не успела бы скопировать на диск индекс файла из-за сбоя. Также это может случиться, если процесс, удаляя связь файла с каталогом, за- пишет освободившийся индекс на диск, но не успеет откорректировать каталог из-за сбоя. Возникновение подобных ситуаций можно предотвратить, копируя на диск результаты работы в надлежащем порядке. Если число свободных блоков или свободных индексов, записанное в суперб- локе, не совпадает с их количеством на диске, файловая система так же явля- ется несогласованной. Итоговая информация в суперблоке всегда должна соот- ветствовать информации о текущем состоянии файловой системы. 5.19 ВЫВОДЫ Этой главой завершается первая часть книги, посвященная рассмотрению особенностей файловой системы. Глава познакомила пользователя с тремя табли- цами, принадлежащими ядру: таблицей пользовательских дескрипторов файла, системной таблицей файлов и таблицей монтирования. В ней рассмотрены алго- ритмы выполнения системных функций, имеющих отношение к файловой системе, и взаимодействие между этими функциями. Исследованы некоторые абстрактные свойства файловой системы, позволяющие системе UNIX поддерживать файловые системы различных типов. Наконец, описан механизм выполнения команды fsck, контролирующей целостность и согласованность данных в файловой системе. 5.20 УПРАЖНЕНИЯ 1. Рассмотрим программу, приведенную на Рисунке 5.35. Какое значение воз- вращает каждая операция read и что при этом содержится в буфере ? Опи- 131 шите, что происходит в ядре во время выполнения каждого вызова read. 2. Вновь вернемся к программе на Рисунке 5.35 и предположим, что оператор lseek(fd,9000L,0); стоит перед первым обращением к функции read. Что ищет процесс и что при этом происходит в ядре ? 3. Процесс может открыть файл для работы в режиме добавления записей в конец файла, при этом имеется в виду, что каждая операция записи рас- полагает данные по адресу смещения, указывающего текущий конец файла. Таким образом, два процесса могут открыть файл для работы в режиме до- бавления записей в конец файла и вводить данные, не опасаясь затереть записи друг другу. Что произойдет, если процесс откроет файл в режиме добавления в конец, а записывающую головку установит на начало файла ? 4. Библиотека стандартных подпрограмм ввода-вывода повышает эффективность выполнения пользователем операций чтения и записи благодаря буфериза- ции данных в библиотеке и сохранению большого количества модулей обра- щения к операционной системе, необходимых пользователю. Как бы вы реа- лизовали библиотечные функции fread и fwrite ? Что должны делать биб- лиотечные функции fopen и fclose ? +------------------------------------------------------------+ | #include | | main() | | { | | int fd; | | char buf[1024]; | | fd = creat("junk",0666); | | lseek(fd,2000L,2); /* ищется байт с номером 2000 */ | | write(fd,"hello",5); | | close(fd); | | | | fd = open("junk",O_RDONLY); | | read(fd,buf,1024); /* читает нули */ | | read(fd,buf,1024); /* считывает нечто, отличное от 0 */| | read(fd,buf,1024); | | } | +------------------------------------------------------------+ Рисунок 5.35. Считывание нулей и конца файла 5. Если процесс читает данные из файла последовательно, ядро запоминает значение блока, прочитанного с продвижением, в индексе, хранящемся в памяти. Что произойдет, если несколько процессов будут одновременно вести последовательное считывание данных из одного и того же файла ? +---------------------------------------------------------+ | #include | | main() | | { | | int fd; | | char buf[256]; | | | | fd = open("/etc/passwd",O_RDONLY); | | if (read(fd,buf,1024) < 0) | | printf("чтение завершается неудачно\n"); | | } | +---------------------------------------------------------+ Рисунок 5.36. Чтение большой порции данных в маленький буфер 132 6. Рассмотрим программу, приведенную на Рисунке 5.36. Что произойдет в результате выполнения программы ? Обоснуйте ответ. Что произошло бы, если бы объявление массива buf было вставлено между объявлениями двух других массивов размером 1024 элемента каждый ? Каким образом ядро ус- танавливает, что прочитанная порция данных слишком велика для буфера ? *7. В файловой системе BSD разрешается фрагментировать последний блок фай- ла в соответствии со следующими правилами: * Свободные фрагменты отслеживаются в структурах, подобных суперблоку; * Ядро не поддерживает пул ранее выделенных свободных фрагментов, а разбивает на фрагменты в случае необходимости свободный блок; * Ядро может назначать фрагменты блока только для последнего блока в файле; * Если блок разбит на несколько фрагментов, ядро может назначить их различным файлам; * Количество фрагментов в блоке не должно превышать величину, фиксиро- ванную для данной файловой системы; * Ядро назначает фрагменты во время выполнения системной функции write. Разработайте алгоритм, присоединяющий к файлу фрагменты блока. Какие изменения должны быть сделаны в индексе, чтобы позволить использование фрагментов ? Какие преимущества с системной точки зрения предоставляет использование фрагментов для тех файлов, которые используют блоки кос- венной адресации ? Не выгоднее ли было бы назначать фрагменты во время выполнения функции close вместо того, чтобы назначать их при выполне- нии функции write ? *8. Вернемся к обсуждению, начатому в главе 4 и касающемуся расположения данных в индексе файла. Для того случая, когда индекс имеет размер дискового блока, разработайте алгоритм, по которому остаток данных файла переписывается в индексный блок, если помещается туда. Сравните этот метод с методом, предложенным для решения предыдущей проблемы. *9. В версии V системы функция fcntl используется для реализации механизма захвата файла и записи и имеет следующий формат: fcntl(fd,cmd,arg); где fd - дескриптор файла, cmd - тип блокирующей операции, а в arg указываются различные параметры, такие как тип блокировки (записи или чтения) и смещения в байтах (см. приложение). К блокирующим операциям относятся * Проверка наличия блокировок, принадлежащих другим процессам, с не- медленным возвратом управления в случае обнаружения таких блокиро- вок, * Установка блокировки и приостанов до успешного завершения, * Установка блокировки с немедленным возвратом управления в случае не- удачи. Ядро автоматически снимает блокировки, установленные процессом, при закрытии файла. Опишите работу алгоритма, реализующего захват файла и записи. Если блокировки являются обязательными, другим процессам сле- дует запретить доступ к файлу. Какие изменения следует сделать в опе- рациях чтения и записи ? *10. Если процесс приостановил свою работу в ожидании снятия с файла блоки- ровки, возникает опасность взаимной блокировки: процесс A может забло- кировать файл "one" и попытаться заблокировать файл "two", а процесс B может заблокировать файл "two" и попытаться заблокировать файл "one". Оба процесса перейдут в состояние, при котором они не смогут продол- жить свою работу. Расширьте алгоритм решения предыдущей проблемы таким образом, чтобы ядро могло обнаруживать ситуации взаимной блокировки и прерывать выполнение системных функций. Следует ли поручать обнаруже- ние взаимных блокировок ядру ? 11. До существования специальной системной функции захвата файла пользова- телям приходилось прибегать к услугам параллельно действующих процес- 133 сов для реализации механизма захвата путем вызова системных функций, выполняющих элементарные действия. Какие из системных функций, описан- ных в этой главе, могли бы использоваться ? Какие опасности подстере- гают при использовании этих методов ? 12. Ричи заявлял (см. [Ritchie 81]), что захвата файла недостаточно для того, чтобы предотвратить путаницу, вызываемую такими программами, как редакторы, которые создают копию файла при редактировании и переписы- вают первоначальный файл по окончании работы. Объясните, что он имел в виду, и прокомментируйте. 13. Рассмотрим еще один способ блокировки файлов, предотвращающий разруши- тельные последствия корректировки. Предположим, что в индексе содер- жится новая установка прав доступа, позволяющая только одному процессу в текущий момент открывать файл для записи и нескольким процессам отк- рывать файл для чтения. Опишите реализацию этого способа. +----------------------------------------------------------+ | main(argc,argv) | | int argc; | | char *argv[]; | | { | | if (argc != 2) | | { | | printf("введите: команда имя каталога\n"); | | exit(); | | } | | | | /* права доступа к каталогу: запись, чтение и ис- | | полнение разрешены для всех */ | | /* только суперпользователь может делать следую- | | щее */ | | if (mknod(argv[1],040777,0) == -1) | | printf("mknod завершилась неудачно\n"); | | } | +----------------------------------------------------------+ Рисунок 5.37. Каталог, создание которого не завершено *14. Рассмотрим программу (Рисунок 5.37), которая создает каталог с невер- ным форматом (в каталоге отсутствуют записи с именами "." и ".."). Попробуйте, находясь в этом каталоге, выполнить несколько команд, та- ких как ls -l, ls -ld, или cd. Что произойдет при этом ? 15. Напишите программу, которая выводит для файлов, имена которых указаны в качестве параметров, информацию о владельце, типе файла, правах дос- тупа и времени доступа. Если файл (параметр) является каталогом, прог- рамма должна читать записи из каталога и выводить вышеуказанную инфор- мацию для всех файлов в каталоге. 16. Предположим, что у пользователя есть разрешение на чтение из каталога, но нет разрешения на исполнение. Что произойдет, если каталог исполь- зовать в качестве параметра команды ls, заданной с опцией "-i" ? Что будет, если указана опция "-l" ? Поясните свои ответы. Ответьте на вопрос, сформулированный для случая, когда есть разрешение на исполне- ние, но нет разрешения на чтение из каталога. 17. Сравните права доступа, которые должны быть у процесса для выполнения следующих действий, и прокомментируйте: * Для создания нового файла требуется разрешение на запись в каталог. * Для "создания" существующего файла требуется разрешение на запись в файл. * Для удаления связи файла с каталогом требуется разрешение на запись 134 в каталог, а не в файл. *18. Напишите программу, которая навещает все каталоги, начиная с текущего. Как она должна управлять циклами в иерархии каталогов ? 19. Выполните программу, приведенную на Рисунке 5.38, и объясните, что при этом происходит в ядре. (Намек: выполните команду pwd, когда программа закончится). 20. Напишите программу, которая заменяет корневой каталог указанным ката- логом, и исследуйте дерево каталогов, доступное для этой программы. 21. Почему процесс не может отменить предыдущий вызов функции chroot ? Из- мените конкретную реализацию процесса таким образом, чтобы он мог ме- нять текущее значение корня на предыдущее. Какие у этой возможности преимущества и неудобства ? 22. Рассмотрим простой пример канала (Рисунок 5.19), когда процесс записы- вает в канал строку "hello" и затем считывает +----------------------------------------------------------+ | main(argc,argv) | | int argc; | | char *argv[]; | | { | | if (argc != 2) | | { | | printf("нужен 1 аргумент - имя каталога\n"); | | exit(); | | } | | | | if (chdir(argv[1]) == -1) | | printf("%s файл не является каталогом\n",argv[1]);| | } | +----------------------------------------------------------+ Рисунок 5.38. Пример программы с использованием функции chdir ее. Что произошло бы, если бы массив для записи данных в канал имел размер 1024 байта вместо 6 (а объем считываемых за одну операцию дан- ных оставался равным 6) ? Что произойдет, если порядок вызова функций read и write в программе изменить, поменяв функции местами ? 23. Что произойдет при выполнении программы, иллюстрирующей использование поименованных каналов (Рисунок 5.19), если функция mknod обнаружит, что канал с таким именем уже существует ? Как этот момент реализуется ядром ? Что произошло бы, если бы вместо подразумеваемых в тексте программы одного считывающего и одного записывающего процессов связь между собой через канал попытались установить несколько считывающих и записывающих процессов ? Как в этом случае гарантировалась бы связь одного считывающего процесса с одним записывающим процессом ? 24. Открывая поименованный канал для чтения, процесс приостанавливается до тех пор, пока еще один процесс не откроет канал для записи. Почему ? Не мог бы процесс успешно пройти функцию open, продолжить работу до того момента, когда им будет предпринята попытка чтения данных из ка- нала, и приостановиться при выполнении функции read ? 25. Как бы вы реализовали алгоритм выполнения системной функции dup2 (из версии 7), вызываемой следующим образом: dup2(oldfd,newfd); где oldfd - файловый дескриптор, который дублируется дескриптором newfd ? Что произошло бы, если бы дескриптор newfd уже принадлежал от- крытому файлу? *26. Какие последствия имело бы решение ядра позволить двум процессам од- новременно смонтировать одну и ту же файловую систему в двух точках монтирования ? 135 27. Предположим, что один процесс меняет свой текущий каталог на каталог "/mnt/a/b/c", после чего другой процесс в каталоге "/mnt" монтирует файловую систему. Завершится ли функция mount успешно ? Что произой- дет, если первый процесс выполнит команду pwd ? Ядро не позволит функ- ции mount успешно завершиться, если значение счетчика ссылок в индексе каталога "/mnt" превышает 1. Прокомментируйте этот момент. 28. При исполнении алгоритма пересечения точки монтирования по имени ".." в маршруте поиска файла ядро проверяет выполнение трех условий, свя- занных с точкой монтирования: что номер обнаруженного индекса совпада- ет с номером корневого индекса, что рабочий индекс является корнем файловой системы и что имя компоненты маршрута поиска - "..". Почему необходимо проверять выполнение всех трех условий ? Докажите, что про- верки любых двух условий недостаточно для того, чтобы разрешить про- цессу пересечь точку монтирования. 29. Если пользователь монтирует файловую систему только для чтения, ядро устанавливает соответствующий флаг в суперблоке. Как ядро может восп- репятствовать выполнению операций записи в функциях write, creat, link, unlink, chown и chmod ? Какого рода информацию записывают в фай- ловую систему все перечисленные функции ? *30. Предположим, что один процесс пытается демонтировать файловую систему, в то время как другой процесс пытается создать в файловой системе но- вый файл. Только одна из функций umount и creat выполнится успешно. Подробно рассмотрите возникшую конкуренцию. *31. Когда функция umount проверяет отсутствие в файловой системе активных файлов, возникает одна проблема, связанная с тем, что корневой индекс файловой системы, назначаемый при выполнении функции mount с помощью алгоритма iget, имеет счетчик ссылок с положительным значением. Как функция umount сможет убедиться в отсутствии активных файлов и отчи- таться перед корнем файловой системы ? Рассмотрите два случая: * функция umount освобождает корневой индекс по алгоритму iput перед проверкой активных индексов. (Как функции вернуть этот индекс обрат- но, если будут обнаружены активные файлы ?) * функция umount проверяет отсутствие активных файлов до того, как ос- вободить корневой индекс, и разрешая корневому индексу оставаться активным. (Насколько активным может быть корневой индекс ?) 32. Обратите внимание на то, что при выполнении команды ls -ld количество связей с каталогом никогда не равно 1. Почему ? 33. Как работает команда mkdir (создать новый каталог) ? (Наводящий воп- рос: какие номера по завершении выполнения команды имеют индексы для файлов "." и ".." ?) *34. Понятие "символические связи" имеет отношение к возможности указания с помощью функции link связей между файлами, принадлежащими к различным файловым системам. С файлом символической связи ассоциирован указатель нового типа; содержимым файла является имя пути поиска того файла, с которым он связан. Опишите реализацию символических связей. *35. Что произойдет, если процесс вызовет функцию unlink("."); Каким будет текущий каталог процесса ? Предполагается, что процесс об- ладает правами суперпользователя. 36. Разработайте системную функцию, которая усекает существующий файл до произвольных размеров, указанных в качестве аргумента, и опишите ее работу. Реализуйте системную функцию, которая позволяла бы пользовате- лю удалять сегмент файла, расположенный между двумя адресами, заданны- ми в виде смещений, и сжимать файл. Напишите программу, которая не вы- зывала бы эти функции, но обладала бы теми же функциональными возмож- ностями. 37. Опишите все условия, при которых счетчик ссылок в индексе может превы- шать значение 1. 38. Затрагивая тему абстрактных обращений к файловым системам, ответьте на вопрос: следует ли файловой системе каждого типа иметь личную операцию блокирования, вызываемую из общей программы, или же достаточно общей операции блокирования ? 136