Читать онлайн «Linux программирование в примерах». Страница 57

Обеспечение доступа к разделу, содержащему файловую систему, называется монтированием (mounting) файловой системы. Удаление файловой системы из использования называется, что неудивительно, демонтированием (unmounting) файловой системы.

Эти две задачи выполняются программами mount и umount [так], названными по соответствующим системным вызовам. У системного вызова mount() каждой системы Unix свой, отличный интерфейс. Поскольку монтирование и демонтирование считаются проблемой реализации, POSIX намеренно не стандартизует эти системные вызовы

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

Ядро поддерживает уникальный номер, известный как номер устройства, который идентифицирует каждый смонтированный раздел. По этой причине именно пара (устройство, индекс) вместе уникально идентифицируют файл; когда структуры struct stat для двух имен файлов указывают, что оба эти номера одни и те же, можно быть уверенным, что они на самом деле ссылаются на один и тот же файл.

Как упоминалось ранее, программы уровня пользователя помещают структуры индексов и другие вспомогательные данные на раздел диска, создавая тем самым файловую систему. Эти самые программы создают для файловой системы начальный корневой каталог. Таким образом, нам придется провести различие между «корневым каталогом, названным /», который является каталогом самого верхнего уровня в иерархическом пространстве имен файлов, и «корневым каталогом файловой системы», который является отдельным каталогом верхнего уровня каждой файловой системы. Каталог / является также «корневым каталогом» «корневой файловой системы».

По причинам, описанным на врезке, у корневого каталога файловой системы номер индекса всегда равен 2 (хотя это не стандартизовано формально). Поскольку может быть несколько файловых систем, у каждой из них один и тот же номер индекса корневого каталога 2. При разрешении пути ядро знает, где смонтирована каждая файловая система и заставляет имя точки монтирования ссылаться на корневой каталог смонтированной файловой системы. Более того, '..' в корне смонтированной файловой системы ссылается на родительский каталог точки монтирования.

На рис. 8.1 показаны две файловые системы: одна для корневого каталога, а другая для /usr, до того, как /usr смонтирована. На рис. 8.2 показана ситуация после монтирования /usr.

Рис. 8.1. Отдельные файловые системы до монтирования

Рис. 8.2. Отдельные файловые системы после монтирования

Каталог /, корень всей логической иерархии, особый еще в одном отношении: /. и /.. ссылаются на один и тот же каталог; это неверно для любого другого каталога в системе. (Таким образом, после команды типа 'cd /../../../..' вы все еще будете в /.) Это поведение реализуется простым способом: как /., так и /.. являются прямыми ссылками на корневой каталог файловой системы. (Вы можете видеть это как на рис. 8.1, так и 8.2.) Каждая файловая система работает таким способом, но ядро рассматривает / особым образом и не рассматривает как особый случай каталог '..' для файловой системы, смонтированной в /.

Номера индексов корневого каталога

Номер индекса для корневого каталога файловой системы всегда равен 2. Почему это так? Ответ имеет отношение как к технологии, так и к истории.

Как упоминалось в разделе 5.3 «Чтение каталогов», элемент каталога с номером индекса ноль означает неиспользуемый, или пустой слот. Поэтому индекс 0 не может использоваться для настоящего файла или каталога.

Хорошо, так что насчет индекса 1? Ну, особенно в 70-80 годах XX века, диски не были сделаны так же хорошо, как сейчас. Когда вы покупали диск, он приходил с (бумажным) списком испорченных блоков — известных мест на диске, которые не могли быть использованы. Каждой операционной системе приходилось отслеживать эти плохие блоки и избегать их использования.

Под Unix это осуществлялось созданием файла особого назначения, блоки данных которого были известны, как испорченные. Этот файл присоединялся к индексу 1, оставляя 2 в качестве первого индекса, доступного для использования обычными файлами или каталогами.

На современных дисках присутствует значительное количество встроенной электроники, и они сами управляют испорченными блоками. Поэтому технически было бы осуществимо использовать для файла индекс 1. Однако, поскольку такое большое количество программ Unix, которые предполагают, что индекс 2 является индексом для корневых каталогов файловых систем, Linux также следует этому соглашению. (Однако, Linux иногда использует индекс 1 для не собственных файловых систем, таких, как vfat или /proc.)

ЗАМЕЧАНИЕ. Обсуждение в данном разделе специфично для 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 никогда широко не использовалась и сейчас является лишь исторической сноской.)

Общий дизайн Sun стал популярным и широко реализовывался в коммерческих системах Unix, включая System V Release 4. Системы Linux и BSD используют разновидность этого дизайна для поддержки множества форматов файловых систем на диске. В частности, обычным для всех разновидностей Unix на платформе Intel x86 является возможность монтирования файловых систем MS-DOS/Windows FAT, включая поддержку длинных имен, а также форматированные в соответствии с ISO 9660 CD-ROM.

Linux имеет несколько собственных (т.е. размещаемых на диске) файловых систем. Наиболее популярными являются файловые системы ext2 и ext3. Однако, доступно значительно больше файловых систем. Сведения о большинстве из них вы можете найти в каталоге /usr/src/linux/Documentation/filesystems/ (если вы установили исходный код ядра). В табл. 8.1 перечислены имена различных файловых систем с кратким описанием каждой из них. Сокращение «RW» означает «чтение/запись», a «RO» означает «только чтение».

Таблица 8.1. Поддерживаемые ядром файловые системы Linux (ядро 2.4.x)

Имя Режим Описание afs RW Andrew File System (файловая система Andrew) adfs RW Acorn Advanced Disc Filing System (расширенная дисковая файловая система Acorn) affs RO, RW Amiga Fast File system (быстрая файловая система Amiga) Режим «только для чтения» в противоположность режиму «для записи и чтения» зависит от версии файловой системы autofs RW Файловая система для взаимодействия с демоном автоматического монтирования befs RO Файловая система BeOS. Помечена как программное обеспечение альфа. bfs RW SCO UnixWare Boot File system (загрузочная файловая система SCO Unix). binfmt-misc RW Специальная файловая система для запуска интерпретаторов компилированных файлов (например, файлов Java) efs RW Файловая система, разработанная для варианта Unix SGI, названного Irix coda RW Экспериментальная распределенная файловая система, разработанная в CMU[79] cramfs RO Небольшая файловая система для хранения файлов в постоянной памяти (ROM). devfs RW Способ динамического предоставления файлов для /dev (устарело). devpts RW Специальная файловая система для псевдотерминалов. ext2 RW Вторая расширенная файловая система. Файловая система по умолчанию для GNU/Linux, хотя некоторые дистрибутивы используют теперь ext3. ext3 RW Файловая система ext2 с журналированием hfs RW Hierarchical File System (иерархическая файловая система) Apple Mac OS. hpfs RW High Performance File System (высокопроизводительная файловая система) OS/2. intermezzo RW Экспериментальная распределенная файловая система для работы в отсоединенном от сети состоянии. См веб-сайт InterMezzo (http://www.inter-mezzo.org) jffs RW Journalled Flash File system (журналируемая файловая система с групповой записью/считыванием, для встроенных систем) jffs2 RW Journalled Flash File system 2 (тоже для встроенных систем) iso9660 RO Файловая система ISO 9660 для CD-ROM. Поддерживаются также расширения Rock Ridge, заставляющие выглядеть использующие их CD-ROM как нормальная файловая система (но только для чтения). jfs RW Journalled File System (журналируемая файловая система) IBM для Linux. ncp RW Протокол Novell NCP для NetWare; клиент удаленной файловой системы. ntfs RO Поддержка файловой системы NTFS Windows openpromfs RO Файловая система /proc для PROM на системах SPARC proc RW Доступ к информации о процессах и ядре qnx4 RW Файловая система QNX4 (небольшой операционной системы реального времени) ramfs RW Файловая система для создания RAM-дисков. reiserfs RW Развитая журналируемая файловая система romfs RO Файловая система для создания простых RAM-дисков только для чтения. smbfs RW Поддержка клиента для файловых систем SMB (разделяемых файлов Windows) sysv RW Файловые системы System V Release 2, Xenix, Minix и Coherent. coherent, minix и xenix являются псевдонимами tmpfs RW Файловая система электронного диска, поддерживающая динамический рост. udf RO Формат файловой системы UDF, используемый в DVD-ROM ufs RO, RW Быстрая файловая система BSD, на современных системах с доступом для чтения и записи. umsdos RW Расширение vfat, заставляющее выглядеть ее подобно файловой системе Unix usbfs RW Специальная файловая система для работы с устройствами USB. Первоначальным именем было usbdevfs, это имя до сих пор появляется, например, в выводе mount vfat RW Все варианты файловых систем FAT MS-DOS/Windows Компонентами являются msdos и fat vxfs RW Журналируемая файловая система Veritas VxFS. xfs RW Высокопроизводительная журналирующая файловая система, разработанная SGI для Linux. См веб-сайт XFS (http://oss.sgi.com/projects/xfs/)

Не все из этих файловых систем поддерживаются командой mount; список поддерживаемых см. в mount(8).