Linux программирование в примерах
Шрифт:
8.1.1. Обзор основ
В главе 5 «Каталоги и служебные данные файлов», были представлены индексы для служебных данных файлов и описано, как элементы каталогов связывают имена файлов с индексами В ней также были описаны разделы и файловые системы, и вы видели, что прямые ссылки ограничены работой в пределах одной файловой системы, поскольку каталоги содержат лишь номера индексов, а последние не уникальны среди всего набора использующихся файловых систем.
Помимо индексов и блоков данных, файловые системы содержат также одну или более копий суперблока. Это специальный дисковый блок, который описывает файловую систему; его сведения обновляются по мере изменений в самой файловой системе. Например, он содержит число свободных и используемых индексов, свободных и используемых блоков и другие сведения. Он включает также магическое число: специальное уникальное значение в специальном месте, которое идентифицирует
Обеспечение доступа к разделу, содержащему файловую систему, называется монтированием (mounting) файловой системы. Удаление файловой системы из использования называется, что неудивительно, демонтированием (unmounting) файловой системы.
Эти две задачи выполняются программами
Вы монтируете файловую систему в каталог; такой каталог называется точкой монтирования файловой системы. По соглашению, каталог должен быть пустым, но ничто не принуждает к этому. Однако, если точка монтирования не пуста, все ее содержимое становится , пока в ней не смонтирована файловая система [76] .
Ядро поддерживает уникальный номер, известный как номер устройства, который идентифицирует каждый смонтированный раздел. По этой причине именно пара (устройство, индекс) вместе уникально идентифицируют файл; когда структуры
76
GNU/Linux и Solaris дают возможность монтировать один файл поверх другого; это продвинутое использование, которое мы не будем обсуждать — Примеч. автора.
Как упоминалось ранее, программы уровня пользователя помещают структуры индексов и другие вспомогательные данные на раздел диска, создавая тем самым файловую систему. Эти самые программы создают для файловой системы начальный корневой каталог. Таким образом, нам придется провести различие между «корневым каталогом, названным
По причинам, описанным на врезке, у корневого каталога файловой системы номер индекса всегда равен 2 (хотя это не стандартизовано формально). Поскольку может быть несколько файловых систем, у каждой из них один и тот же номер индекса корневого каталога 2. При разрешении пути ядро знает, где смонтирована каждая файловая система и заставляет имя точки монтирования ссылаться на корневой каталог смонтированной файловой системы. Более того, '
На рис. 8.1 показаны две файловые системы: одна для корневого каталога, а другая для
Рис. 8.1. Отдельные файловые системы до монтирования
Рис. 8.2. Отдельные файловые системы после монтирования
Каталог
Номер индекса для корневого каталога файловой системы всегда равен 2. Почему это так? Ответ имеет отношение как к технологии, так и к истории.
Как упоминалось в разделе 5.3 «Чтение каталогов», элемент каталога с номером индекса ноль означает неиспользуемый, или пустой слот. Поэтому индекс 0 не может использоваться для настоящего файла или каталога.
Хорошо, так что насчет индекса 1? Ну, особенно в 70-80 годах XX века, диски не были сделаны так же хорошо, как сейчас. Когда вы покупали диск, он приходил с (бумажным) списком испорченных блоков — известных мест на диске, которые не могли быть использованы. Каждой операционной системе приходилось отслеживать эти плохие блоки и избегать их использования.
Под Unix это осуществлялось созданием файла особого назначения, блоки данных которого были известны, как испорченные. Этот файл присоединялся к индексу 1, оставляя 2 в качестве первого индекса, доступного для использования обычными файлами или каталогами.
На современных дисках присутствует значительное количество встроенной электроники, и они сами управляют испорченными блоками. Поэтому технически было бы осуществимо использовать для файла индекс 1. Однако, поскольку такое большое количество программ Unix, которые предполагают, что индекс 2 является индексом для корневых каталогов файловых систем, Linux также следует этому соглашению. (Однако, Linux иногда использует индекс 1 для не собственных файловых систем, таких, как
8.1.2. Обзор различных типов файловых систем
ЗАМЕЧАНИЕ. Обсуждение в данном разделе специфично для Linux. Однако, у многих современных систем Unix также есть сходные особенности. Мы рекомендуем вам изучить документацию своей системы.
Исторически V7 Unix поддерживал лишь один тип файловой системы; вспомогательные данные и организация каталогов каждого из разделов были структурированы одним и тем же способом. 4.1 BSD использовал файловую систему с такой же как у V7 структурой, но с размером блока 1024 байта вместо 512 байтов. 4.2 BSD ввело «файловую систему BSD», которая разительно изменила расположение индексов и данных на диске и дала возможность использовать гораздо большие размеры блоков. (В общем, использование больших протяженных блоков данных обеспечивает лучшую производительность, особенно для чтения файлов.)
Вплоть до 4.3 BSD и System V Release 2 в начале и середине 1980-х системы Unix продолжали поддерживать один тип файловой системы. Для переключения компьютера от одной файловой системы на другую [77] приходилось сначала резервировать каждую файловую систему на среду архивирования (9-дорожечную ленту), обновлять систему, а затем восстанавливать данные.
В середине 1980-х Sun Microsystems разработала архитектуру ядра, которая сделала возможным использование нескольких архитектур файловой системы в одно и то же время. Этот проект был реализован в их операционной системе SunOS, сначала для поддержки сетевой файловой системы Sun (Network File System — NFS). Однако, как следствие, стало возможным также поддерживать несколько архитектур на диске. System V Release 3 использовала сходную архитектуру для поддержки удаленной файловой системы (Remote File System — RFS), но она продолжала поддерживать лишь одну архитектуру на диске. [78] (RFS никогда широко не использовалась и сейчас является лишь исторической сноской.)
77
Например, при обновлении VAX 11/780 с 4.1 BSD до 4.2 BSD — Примеч. автора.
78
System V Release 3 поддерживала два различных размера блоков: 512 байтов и 1024 байта, но в остальном организация диска была той же самой — Примеч. автора.
Общий дизайн Sun стал популярным и широко реализовывался в коммерческих системах Unix, включая System V Release 4. Системы Linux и BSD используют разновидность этого дизайна для поддержки множества форматов файловых систем на диске. В частности, обычным для всех разновидностей Unix на платформе Intel x86 является возможность монтирования файловых систем MS-DOS/Windows FAT, включая поддержку длинных имен, а также форматированные в соответствии с ISO 9660 CD-ROM.
Linux имеет несколько собственных (т.е. размещаемых на диске) файловых систем. Наиболее популярными являются файловые системы