Структура файловой системы Linux и UNIX

--PAGE_BREAK--Структура файловой системы
Файловая система обычно размещается на дисках или других устройствах внешней памяти, имеющих блочную структуру. Кроме блоков, сохраняющих каталоги и файлы, во внешней памяти поддерживается еще несколько служебных областей.

В мире UNIX существует несколько разных видов файловых систем со своей структурой внешней памяти. Наиболее известны традиционная файловая система UNIX System V (s5) и файловая система семейства UNIX BSD (ufs). Файловая система s5 состоит из четырех секций (рисунок 2.2,a). В файловой системе ufs на логическом диске (разделе реального диска) находится последовательность секций файловой системы (рисунок 2.2,b).



Рис. 2.2. Структура внешней памяти файловых систем s5 и ufs

Кратко опишем суть и назначение каждой области диска.
Boot-блок содержит программу раскрутки, которая служит для первоначального запуска ОС UNIX. В файловых системах s5 реально используется boot-блок только корневой файловой системы. В дополнительных файловых системах эта область присутствует, но не используется. Суперблок — это наиболее ответственная область файловой системы, содержащая информацию, которая необходима для работы с файловой системой в целом. Суперблок содержит список свободных блоков и свободные i-узлы (information nodes — информационные узлы). В файловых системах ufs для повышения устойчивости поддерживается несколько копий суперблока (как видно из рисунка 2.2,b, по одной копии на группу цилиндров). Каждая копия суперблока имеет размер 8196 байт, и только одна копия суперблока используется при монтировании файловой системы (см. ниже). Однако, если при монтировании устанавливается, что первичная копия суперблока повреждена или не удовлетворяет критериям целостности информации, используется резервная копия. Блок группы цилиндров содержит число i-узлов, специфицированных в списке i-узлов для данной группы цилиндров, и число блоков данных, которые связаны с этими i-узлами. Размер блока группы цилиндров зависит от размера файловой системы. Для повышения эффективности файловая система ufs старается размещать i-узлы и блоки данных в одной и той же группе цилиндров. Список i-узлов (ilist) содержит список i-узлов, соответствующих файлам данной файловой системы. Максимальное число файлов, которые могут быть созданы в файловой системе, определяется числом доступных i-узлов. В i-узле хранится информация, описывающая файл: режимы доступа к файлу, время создания и последней модификации, идентификатор пользователя и идентификатор группы создателя файла, описание блочной структуры файла и т.д. Блоки данных — в этой части файловой системы хранятся реальные данные файлов. В случае файловой системы ufs все блоки данных одного файла пытаются разместить в одной группе цилиндров. Размер блока данных определяется при форматировании файловой системы командой mkfs и может быть установлен в 512, 1024, 2048, 4096 или 8192 байтов. Монтируемые файловые системы
Файлы любой файловой системы становятся доступными только после «монтирования» этой файловой системы. Файлы «не смонтированной» файловой системы не являются видимыми операционной системой.

Для монтирования файловой системы используется системный вызов mount. Монтирование файловой системы означает следующее. В имеющемся к моменту монтирования дереве каталогов и файлов должен иметься листовой узел — пустой каталог (в терминологии UNIX такой каталог, используемый для монтирования файловой системы, называется directory mount point — точка монтирования). В любой файловой системе имеется корневой каталог. Во время выполнения системного вызова mount корневой каталог монтируемой файловой системы совмещается с каталогом — точкой монтирования, в результате чего образуется новая иерархия с полными именами каталогов и файлов.

Смонтированная файловая система впоследствии может быть отсоединена от общей иерархии с использованием системного вызова umount. Для успешного выполнения этого системного вызова требуется, чтобы отсоединяемая файловая система к этому моменту не находилась в использовании (т.е. ни один файл из этой файловой системы не был открыт). Корневая файловая система всегда является смонтированной, и к ней не применим системный вызов umount.

Как мы отмечали выше, отдельная файловая система обычно располагается на логическом диске, т.е. на разделе физического диска. Для инициализации файловой системы не поддерживаются какие-либо специальные системные вызовы. Новая файловая система образуется на отформатированном диске с использованием утилиты (команды) mkfs. Вновь созданная файловая система инициализируется в состояние, соответствующее наличию всего лишь одного пустого корневого каталога. Команда mkfs выполняет инициализацию путем прямой записи соответствующих данных на диск.
Интерфейс с файловой системой
Ядро ОС UNIX поддерживает для работы с файлами несколько системных вызовов. Среди них наиболее важными являются open, creat, read, write, lseek и close.

Важно отметить, что хотя внутри подсистемы управления файлами обычный файл представляется в виде набора блоков внешней памяти, для пользователей обеспечивается представление файла в виде линейной последовательности байтов. Такое представление позволяет использовать абстракцию файла при работе в внешними устройствами, при организации межпроцессных взаимодействий и т.д.

Файл в системных вызовах, обеспечивающих реальный доступ к данным, идентифицируется своим дескриптором (целым значением). Дескриптор файла выдается системными вызовами open (открыть файл) и creat (создать файл). Основным параметром операций открытия и создания файла является полное или относительное имя файла. Кроме того, при открытии файла указывается также режим открытия (только чтение, только запись, запись и чтение и т.д.) и характеристика, определяющая возможности доступа к файлу:

open(pathname, oflag [,mode])

Одним из признаков, которые могут участвовать в параметре oflag, является признак O_CREAT, наличие которого указывает на необходимость создания файла, если при выполнении системного вызова open файл с указанным именем не существует (параметр mode имеет смысл только при наличии этого признака). Тем не менее по историческим причинам и для обеспечения совместимости с предыдущими версиями ОС UNIX отдельно поддерживается системный вызов creat, выполняющий практически те же функции.

Открытый файл может использоваться для чтения и записи последовательностей байтов. Для этого поддерживаются два системных вызова:

read(fd, buffer, count) иwrite(fd, buffer, count)

Здесь fd — дескриптор файла (полученный при ранее выполненном системном вызове open или creat), buffer — указатель символьного массива и count — число байтов, которые должны быть прочитаны из файла или в него записаны. Значение функции read или write — целое число, которое совпадает со значением count, если операция заканчивается успешно, равно нулю при достижении конца файла и отрицательно при возникновении ошибок.

В каждом открытом файле существует текущая позиция. Сразу после открытия файл позиционируется на первый байт. Другими словами, если сразу после открытия файла выполняется системный вызов read (или write), то будут прочитаны (или записаны) первые count байтов содержимого файла (конечно, они будут успешно прочитаны только в том случае, если файл реально содержит по крайней мере count байтов). После выполнения системного вызова read (или write) указатель чтения/записи файла будет установлен в позицию count+1 и т.д.

Такой, чисто последовательный стиль работы, оказывается во многих случаях достаточным, но часто бывает необходимо читать или изменять файл с произвольной позиции (например, как без такой возможности хранить в файле прямо индексируемые массивы данных?). Для явного позиционирования файла служит системный вызов

lseek(fd, offset, origin)

Как и раньше, здесь fd — дескриптор ранее открытого файла. Параметр offset задает значение относительного смещения указателя чтения/записи, а параметр origin указывает, относительно какой позиции должно применяться смещение. Возможны три значения параметра origin. Значение 0 указывает, что значение offset должно рассматриваться как смещение относительно начала файла. Значение 1 означает, что значение offset является смещением относительно текущей позиции файла. Наконец, значение 2 говорит о том, что задается смещение относительно конца файла. Заметим, что типом данных параметра offset является long int. Это значит, что, во-первых, могут задаваться достаточно длинные смещения и, во-вторых, смещения могут быть положительными и отрицательными.

Например, после выполнения системного вызова

lseek(fd, 0, 0)

указатель чтения/записи соответствующего файла будет установлен на начало (на первый байт) файла. Системный вызов

lseek(fd, 0, 2)

установит указатель на конец файла. Наконец, выполнение системного вызова

lseek(fd, 10, 1)

приведет к увеличению текущего значения указателя на 10.

Естественно, системный вызов успешно завершается только в том случае, когда заново сформированное значение указателя не выходит за пределы существующих размеров файла.


    продолжение
--PAGE_BREAK--Разновидности файлов
Как мы неоднократно отмечали, в ОС UNIX понятие файла является универсальной абстракцией, позволяющей работать с обычными файлами, содержащимися на устройствах внешней памяти; с устройствами, вообще говоря, отличающимися от устройств внешней памяти; с информацией, динамически генерируемой другими процессами и т.д. Для поддержки этих возможностей единообразным способом файловые системы ОС UNIX поддерживают несколько типов файлов, наиболее существенные из которых мы рассмотрим в этом разделе.
Обычные файлы
Обычные (или регулярные) файлы реально представляют собой набор блоков (возможно, пустой) на устройстве внешней памяти, на котором поддерживается файловая система. Такие файлы могут содержать как текстовую информацию (обычно в формате ASCII), так и произвольную двоичную информацию. Файловая система не предписывает обычным файлам какую-либо структуру, обеспечивая на уровне пользователей представление обычного файла как последовательности байтов. Используя базовые системные вызовы (или функции библиотеки ввода/вывода, которые мы рассмотрим в разделе 4), пользователи могут как угодно структурировать файлы. В частности, многие СУБД хранят базы данных в обычных файлах ОС UNIX.

Для некоторых файлов, которые должны интерпретироваться компонентами самой операционной системы, UNIX поддерживает фиксированную структуру. Наиболее важным примером таких файлов являются объектные и выполняемые файлы. Структура этих файлов поддерживается компиляторами, редакторами связей и загрузчиком. Однако, эта структура неизвестна файловой системе. Для нее такие файлы по-прежнему являются обычными файлами.
Файлы-каталоги
Наличие обычных файлов недостаточно для организации иерархических файловых систем. Требуется наличие каталогов, которые сопоставляют имена файлов или каталогов с их физическим описанием. Каталоги представляют собой особый вид файлов, которые хранятся во внешней памяти подобно обычным файлам, но структура которых поддерживается самой файловой системой.

Структура файла-каталога очень проста. Фактически, каталог — это таблица, каждый элемент которой состоит из двух полей: номера i-узла данного файла в его файловой системе и имени файла, которое связано с этим номером (конечно, этот файл может быть и каталогом). Если просмотреть содержимое текущего рабочего каталога с помощью команды ls -ai, то можно получить, например, следующий вывод:

inode File

number name

_________________________

33.

122…

54 first_file

65 second_file

65 second_again

77 dir2

Этот вывод демонстрирует, что в любом каталоге содержатся два стандартных имени — "." и "..". Имени "." сопоставляется i-узел, соответствующий самому этому каталогу, а имени ".." — i-узел, соответствующий «родительскому» каталогу данного каталога. «Родительским» (parent) каталогом называется каталог, в котором содержится имя данного каталога. Файлы с именами «first_file» и «second_file» — это разные файлы с номерами i-узлов 54 и 65 соответственно. Файл «second_again» представляет пример так называемой жесткой ссылки: он имеет другое имя, но реально описывается тем же i-узлом, что и файл «second_file». Наконец, последний элемент каталога описывает некоторый другой каталог с именем «dir2».

Этот последний файл, как и любой обычный файл, хранится в файловой системе как набор блоков запоминающего устройства. Однако файловая система знает, что на самом деле это каталог со структурой, контролируемой файловой системой. Поэтому файлам-каталогам соответствует особый тип файла (обозначенный в их i-узлах), по отношению к которому возможно выполнение только специального набора системных вызовов:

mkdir, производящего новый каталог,

rmdir, удаляющий пустой (незаполненный) каталог,

getdents, позволяющего прочитать содержимое указанного каталога.

Отсутствует системный вызов, позволяющий прямо писать в файл-каталог. Какими бы правами вы не обладали по отношению к файлу-каталогу, прямая запись информации в него запрещена — прямое следствие фиксированной (и закрытой от пользователей) структуры файлов-каталогов. Запись в файлы-каталоги производится неявно при создании и уничтожении файлов и каталогов, однако читать из файла-каталога при наличии соответствующих прав можно (пример — стандартная утилита ls, которая как раз и пользуется системным вызовом getdents).
Специальные файлы
Специальные файлы не хранят данные. Они обеспечивают механизм отображения физических внешних устройств в имена файлов файловой системы. Каждому устройству, поддерживаемому системой, соответствует, по меньшей мере, один специальный файл. Специальные файлы создаются при выполнении системного вызова mknod, каждому специальному файлу соответствует порция программного обеспечения, называемая драйвером соответствующего устройства. При выполнении чтения или записи по отношению к специальному файлу, производится прямой вызов соответствующего драйвера, программный код которого отвечает за передачу данных между процессом пользователя и соответствующим физическим устройством.

При этом имена специальных файлов можно использовать практически всюду, где можно использовать имена обычных файлов. Например, команда

cp myfile /tmp/kuz

перепишет файл с именем myfile в подкаталогkuz рабочего каталога. В то же время, команда

cp myfile /dev/console

выдаст содержимое файла myfile на системную консоль вашей установки.

Различаются два типа специальных файлов — блочные и символьные (подробности см. в разделе 3.3). Блочные специальные файлы ассоциируются с такими внешними устройствами, обмен с которыми производится блоками байтов данных, размером 512, 1024, 4096 или 8192 байтов. Типичным примером подобных устройств являются магнитные диски. Файловые системы всегда находятся на блочных устройствах, так что в команде mount обязательно указывается некоторое блочное устройство.

Символьные специальные файлы ассоциируются с внешними устройствами, которые не обязательно требуют обмена блоками данных равного размера. Примерами таких устройств являются терминалы (в том числе, системная консоль), последовательные устройства, некоторые виды магнитных лент. Иногда символьные специальные файлы ассоциируются с магнитными дисками.

При обмене данными с блочным устройством система буферизует данные во внутреннем системном кеше. Через определенные интервалы времени система «выталкивает» буфера, при которых содержится метка «измененный». Кроме того, существуют системные вызовы sync и fsync, которые могут использоваться в пользовательских программах, и выполнение которых приводит к выталкиванию измененных буферов из общесистемного пула. Основная проблема состоит в том, что при аварийной остановке компьютера (например, при внезапном выключении электрического питания) содержимое системного кеша может быть утрачено. Тогда внешние блочные файлы могут оказаться в рассогласованном состоянии. Например, может быть не вытолкнут супер-блок файловой системы, хотя файловая система соответствует его вытолкнутому состоянию. Заметим, что в любом случае согласованное состояние файловой системы может быть восстановлено (конечно, не всегда без потерь пользовательской информации).

Обмены с символьными специальными файлами производятся напрямую, без использования системной буферизации.
    продолжение
--PAGE_BREAK--Связывание файлов с разными именами
Файловая система ОС UNIX обеспечивает возможность связывания одного и того же файла с разными именами. Часто имеет смысл хранить под разными именами одну и ту же команду (выполняемый файл) командного интерпретатора. Например, выполняемый файл традиционного текстового редактора ОС UNIX vi обычно может вызываться под именами ex, edit, vi, view и vedit.

Можно узнать имена всех связей данного файла с помощью команды ncheck, если указать в числе ее параметров номер i-узла интересующего файла. Например, чтобы узнать все имена, под которыми возможен вызов редактора vi, можно выполнить следующую последовательность команд (третий аргумент команды ncheck представляет собой имя специального файла, ассоциированного с файловой системой /usr):

$ ls -i /usr/bin/vi

372 /usr/bin/vi

$ ncheck -i 372 /dev/dsk/sc0d0s5

/dev/dsk/sc0d0s5:

372 /usr/bin/edit

372 /usr/bin/ex

372 /usr/bin/vedit

372 /usr/bin/vi

372 /usr/bin/view

Ранее в большинстве версий ОС UNIX поддерживались только так называемые «жесткие» связи, означающие, что в соответствующем каталоге имени связи сопоставлялось имя i-узла соответствующего файла. Новые жесткие связи могут создаваться с помощью системного вызова link. При выполнении этого системного вызова создается новый элемент каталога с тем же номером i-узла, что и ранее существовавший файл.

Начиная с «быстрой файловой системы» университета Беркли, в мире UNIX появились «символические связи». Символическая связь создается с помощью системного вызова symblink. При выполнении этого системного вызова в соответствующем каталоге создается элемент, в котором имени связи сопоставляется некоторое имя файла (этот файл даже не обязан существовать к моменту создания символической связи). Для символической связи создается отдельный i-узел и даже заводится отдельный блок данных для хранения потенциально длинного имени файла.

Для работы с символьными связями поддерживаются три специальных системных вызова:

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

lstat — аналогичен системному вызову stat (получить информацию о файле), но относится к символической ссылке;

lchowm — аналогичен системному вызову chown, но используется для смены пользователя и группы самой символической ссылки.
Именованные программные каналы
Программный канал (pipe) — это одно из наиболее традиционных средств межпроцессных взаимодействий в ОС UNIX. В русской терминологии использовались различные переводы слова pipe (начиная от «трубки» и заканчивая замечательным русским словом «пайп»). Мы считаем, что термин «программный канал» наиболее точно отражает смысл термина «pipe».

Основной принцип работы программного канала состоит в буферизации байтового вывода одного процесса и обеспечении возможности чтения содержимого программного канала другим процессом в режиме FIFO (т.е. первым будет прочитан байт, который раньше всего записан). В любом случае интерфейс программного канала совпадает с интерфейсом файла (т.е. используются те же самые системные вызовы read и write).

Однако различаются два подвида программных каналов — неименованные и именованные. Неименованные программные каналы появились на самой заре ОС UNIX (см. раздел 1.2). Неименованный программный канал создается процессом-предком, наследуется процессами-потомками, и обеспечивает тем самым возможность связи в иерархии порожденных процессов. Интерфейс неименованного программного канала совпадает с интерфейсом файла (более подробно см. п. 3.4.4). Однако, поскольку такие каналы не имеют имени, им не соответствует какой-либо элемент каталога в файловой системе.

Именованному программному каналу обязательно соответствует элемент некоторого каталога и даже собственный i-узел. Другими словами, именованный программный канал выглядит как обычный файл, но не содержащий никаких данных до тех пор, пока некоторый процесс не выполнит в него запись. После того, как некоторый другой процесс прочитает записанные в канал байты, этот файл снова становится пустым. В отличие от неименованных программных каналов, именованные программные каналы могут использоваться для связи любых процессов (т.е. не обязательно процессов, входящих в одну иерархию родства). Интерфейс именованного программного канала практически полностью совпадает с интерфейсом обычного файла (включая системные вызовы open и close), хотя, конечно, необходимо учитывать, что поведение канала отличается от поведения файла (подробности см. в п. 3.4.4).
Файлы, отображаемые в виртуальную память
В современных версиях ОС UNIX (например, в UNIX System V.4) появилась возможность отображать обычные файлы в виртуальную память процесса с последующей работой с содержимым файла не с помощью системных вызовов read, write и lseek, а с помощью обычных операций чтения из памяти и записи в память. Заметим, что этот прием был базовым в историческом предшественнике ОС UNIX — операционной системе Multics (см. раздел 1.1).

Для отображения файла в виртуальную память, после открытия файла выполняется системный вызов mmap, действие которого состоит в том, что создается сегмент разделяемой памяти, ассоциированный с открытым файлом, и автоматически подключается к виртуальной памяти процесса (подробнее о разделяемой памяти см. п. 3.4.1). После этого процесс может читать из нового сегмента (реально будут читаться байты, содержащиеся в файле) и писать в него (реально все записи отображаются в файл). При закрытии файла соответствующий сегмент автоматически отключается от виртуальной памяти процесса и уничтожается, если только файл не подключен к виртуальной памяти некоторого другого процесса.

Несколько процессов могут одновременно открыть один и тот же файл и подключить его к своей виртуальной памяти системным вызовом mmap. Тогда любые изменения, производимые путем записи в соответствующий сегмент разделяемой памяти, будут сразу видны другим процессам.
    продолжение
--PAGE_BREAK--Синхронизация при параллельном доступе к файлам
Исторически в ОС UNIX всегда применялся очень простой подход к обеспечению параллельного (от нескольких процессов) доступа к файлам: система позволяла любому числу процессов одновременно открывать один и тот же файл в любом режиме (чтения, записи или обновления) и не предпринимала никаких синхронизационных действий. Вся ответственность за корректность совместной обработки файла ложилась на использующие его процессы, и система даже не предоставляла каких-либо особых средств для синхронизации доступа процессов к файлу.

В System V.4 появились средства, позволяющие процессам синхронизировать параллельный доступ к файлам. В принципе, было бы логично связать синхронизацию доступа к файлу как к единому целому с системным вызовом open (т.е., например, открытие файла в режиме записи или обновления могло бы означать его монопольную блокировку соответствующим процессом, а открытие в режиме чтения — совместную блокировку). Так поступают во многих операционных системах (начиная с ОС Multics). Однако, по отношению к ОС UNIX такое решение принимать было слишком поздно, поскольку многочисленные созданные за время существования системы прикладные программы опирались на свойство отсутствия автоматической синхронизации.

Поэтому разработчикам пришлось пойти «обходным путем». Ядро ОС UNIX поддерживает дополнительный системный вызов fcntl, обеспечивающий такие вспомогательные функции, относящиеся к файловой системе, как получение информации о текущем режиме открытия файла, изменение текущего режима открытия и т.д. В System V.4 именно на системный вызов fcntl нагружены функции синхронизации.

С помощью этого системного вызова можно установить монопольную или совместную блокировку файла целиком или блокировать указанный диапазон байтов внутри файла. Допускаются два варианта синхронизации: с ожиданием, когда требование блокировки может привести к откладыванию процесса до того момента, когда это требование может быть удовлетворено, и без ожидания, когда процесс немедленно оповещается об удовлетворении требования блокировки или о невозможности ее удовлетворения в данный момент времени.

Установленные блокировки относятся только к тому процессу, который их установил, и не наследуются процессами-потомками этого процесса. Более того, даже если некоторый процесс пользуется синхронизационными возможностями системного вызова fcntl, другие процессы по-прежнему могут работать с тем файлом без всякой синхронизации. Другими словами, это дело группы процессов, совместно использующих файл, — договориться о способе синхронизации параллельного доступа.


Распределенные файловые системы
Основная идея распределенной файловой системы состоит в том, чтобы обеспечить совместный доступ к файлам локальной файловой системы для процессов, которые, вообще говоря, выполняются на других компьютерах. Эта идея может быть реализована многими разными способами, однако в среде ОС UNIX все известные подходы основываются на монтировании удаленной файловой системы к одному из каталогов локальной файловой системы. После выполнения этой процедуры файлы, хранимые в удаленной файловой системе, доступны процессам локального компьютера точно таким же образом, как если бы они хранились на локальном дисковом устройстве.

На рисунке 2.5 приведен пример, в котором два подкаталога удаленной файловой системы-сервера (share и X11) монтируются к двум (пустым) каталогам файловой системы-клиента.



Рис. 2.5. Схема монтирования удаленной файловой системы

В принципе, такая схема обладает и достоинствами, и недостатками. К достоинствам, конечно, относится то, что при работе в сети можно экономить дисковое пространство, поддерживая совместно используемые информационные ресурсы только в одном экземпляре. Но, с другой стороны, пользователи удаленной файловой системы неизбежно будут работать с удаленными файлами существенно более медленно, чем с локальными. Кроме того, реальная возможность доступа к удаленному файлу критически зависит от работоспособности сервера и сети. Заметим, что распространенные в мире UNIX сетевые файловые системы NFS (Network File System — сетевая файловая система) и RFS (Remote File Sharing — совместное использование удаленных файлов) являются достаточно тщательно спроектированными и разработанными продуктами, во многом сглаживающими отмеченные недостатки.
Сетевая файловая система (NFS)
Система NFS была разработана компанией Sun Microsystems как часть ее сетевого продукта ONC (Open Network Computing — открытая сетевая вычислительная обработка). В настоящее время NFS является официальным компонентом UNIX System V Release 4.

NFS разрабатывалась как система, пригодная к использованию не только на разных аппаратных, но и на разных операционных платформах. В настоящее время продукт NFS в соответствии со спецификациями и на основе программного кода Sun Microsystems выпускает более 200 производителей. Отметим, в частности, наличие популярного в России продукта PC-NFS, обеспечивающего клиентскую часть системы в среде MS-DOS. Кроме того, заметим, что имеются и свободно доступные (public domain), и коммерческие варианты NFS.

Первоначально NFS разрабатывалась в среде UNIX BSD 4.2, и для реализации системы потребовалось существенно переделать код системных вызовов файловой системы. При внедрении NFS в среду System V понадобилась значительная переделка ядра ОС. Отмечается, что большая часть изменений в ядре System V Release 4 была связана именно с NFS.

В архитектурном отношении в NFS выделяются три основные части: протокол, серверная часть и клиентская часть. Протокол NFS опирается на примитивы RPC, которые, в свою очередь, построены над протоколом XDR (см. п. 2.7.4). Клиентская часть NFS взаимодействует с серверной частью системы на основе механизма RPC.

Основным достоинством NFS является возможность использования в среде разных операционных систем. Возможным недостатком является то, что независимость от транспортных средств ограничена уровнем такой независимости, присущей RPC. В настоящее время де-факто это означает, что NFS можно использовать только в TCP/IP-ориентированных сетях. (Это еще вопрос — плохо ли это, поскольку стимулирует использование единообразных сетевых механизмов.)
    продолжение
--PAGE_BREAK--Совместное использование удаленных файлов (RFS)
Сетевая файловая система RFS была реализована компанией AT&T в рамках ее продукта UNIX System V Release 3. Функционально она выглядит подобно NFS, т.е. обеспечивает прозрачный доступ к удаленным файлам. Однако реализация системы абсолютно отлична. Основным недостатком RFS является то, что система реализуема только на компьютерах, работающих под управлением ОС UNIX (причем именно UNIX System V с номером выпуска не меньше, чем 3). Но с другой стороны, это решение позволило сохранить для пользователей RFS всю семантику файлов ОС UNIX. В частности (в отличие от NFS), в удаленной файловой системе могут находиться не только обычные файлы и каталоги, но и специальные файлы и именованные программные каналы. Более того, на удаленные файлы распространяются возможности блокировки файлов и/или диапазонов адресов внутри файлов.

Если NFS опирается на протокол RPC, то в RFS используется родной для AT&T протокол обмена сообщениями на основе потоков (другими словами, реализация RFS основана на использовании интерфейса TLI). (Кстати, в этом имеется большой смысл, поскольку механизм RPC во многих случаях является слишком ограничительным.)

Другим преимуществом RPC (тоже связанным с использованием TLI) является независимость системы от используемого транспортного механизма (если, конечно, этот механизм поддерживает спецификации семиуровневой модели ISO/OSI). Поэтому эту систему можно использовать в среде операционных систем, основывающихся на различных сетевых протоколах (ISO/OSI уважают практически все).

            Теперь перейдем собственно к файловой системе Linjx/
Структура файловой системы
LINUX


Человеку, ранее работавшему с DOS или Windows, при общении с Linux прежде всего бросаются в глаза использование символа `/' вместо '\', отсутствие имен дисков (A:, B:, C: и т. д.) и то, что в именах файлов различаются большие и маленькие буквы. Однако другие особенности, не столь заметные с первого взгляда, более существенны. Давайте посмотрим, как устроена в Linux работа с файлами.

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

Хотя Linux поддерживает более десятка самых разных файловых систем, все «иностранные» (foreign) системы так или иначе маскируются под стандартно используемую в этой ОС ext2fs. Давайте с нее и начнем.
Узлы и каталоги
Во времена юности Unix, когда автор Linux еще не ходил в школу, работа с файлами в этой ОС была организована весьма просто: все файлы на диске нумеровались и для каждого создавалась специальная запись — узел (inode; к сожалению, устоявшегося русского перевода этого термина пока нет), где содержалась служебная информация о файле. Имя в состав этой информации не включалось, а связывалось с узлом с помощью ссылки (link). Ссылки оформлялись как пары вида «имя файла — номер узла» и хранились в каталогах. Каталог можно было читать, как обычный файл, однако для его модификации уже тогда требовалось использовать специальные команды.

Найдя по ссылке в каталоге узел, ядро ОС дальше оперировало с файлом, не обращая никакого внимания на его исходное имя, поскольку все необходимые данные (размер файла, права доступа к нему и т. д.) извлекались уже из узла. С тех пор многое изменилось, однако в файловой системе Linux узлы по-прежнему играют важную роль, а вся информация о файле по-прежнему хранится отдельно от его имени.
Сколько имен у файла?
Описанная схема позволяет связать с одним файлом несколько равноправных имен, что в ряде случаев бывает полезно. Сравните, например, характеристики файлов unzip и zipinfo на рис. 1 и 2



Рис. 1. Характеристики файла unzip

(для получения информации использована программа Midnight Commander).



Рис. 2. Характеристики файла zipinfo

Как видим, они совпадают: у обоих файлов одно и то же «положение» (кстати, шестнадцатеричное число 1A328h является номером узла), одинаковая длина и т. д., причем на каждый из файлов имеется по две ссылки — это в действительности и есть два имени. Но, будучи физически одним и тем же файлом, unzip и zipinfo являются различными программами: каждая из них выполняет свои действия и имеет собственный набор опций. Никакой мистики здесь нет — просто в программу в качестве нулевого параметра передается ее имя, по которому она и определяет, что делать дальше.

Далее, в Unix-системах (включая Linux) нет операции удаления файла в смысле DOS/Windows: есть только удаление ссылки на узел — unlink — и ссылки на пустой каталог — rmdir (в некоторых Unix-системах unlink позволяет удалить ссылку на пустой каталог, но в Linux это не так). Сам же файл удаляется автоматически тогда, когда делается недоступным для системы. Это означает, что не должно остаться, во-первых, ни одной ссылки на него, а во-вторых, ни одной работающей с ним активной программы.

Именно поэтому, кстати, в Linux можно обойтись без перезагрузки практически при любом изменении системы (за исключением замены ядра). Чтобы обновить системную библиотеку, вы стираете ее прежнюю версию (т. е. освобождаете соответствующую ссылку) и записываете под тем же именем новую. Ядро откладывает момент удаления библиотеки до тех пор, пока не закончит работу последняя из программ, ее использующих (что может произойти много месяцев спустя). Это весьма удобно, но если не знать о таком поведении системы, можно попасть в неприятную ситуацию.
Монтирование
Однако если ядро ОС учитывает не только состояние файловой системы на диске, но и состояние программ, работающих с файлами, то как быть со сменными носителями? Ведь если просто вынуть из дисковода дискету с файлом, уже не имеющим имени, но еще не удаленным, файловая система будет разрушена; степень повреждения зависит от разных обстоятельств и варьирует от небольших неполадок до полного превращения в руины. Здесь как нельзя лучше подтверждается мысль о том, что наши недостатки — это продолжение наших достоинств.

Чтобы избежать подобных эффектов, любую файловую систему необходимо перед началом работы с ней в явной форме подключить к ОС (смонтировать — mount), а по окончании отключить (размонтировать — unmount). Для этой цели служат команды mount и umount (без n, хотя соответствующее действие называется unmount). Команда mount имеет множество опций (см. врезку «Монтирование: подробности для любознательных»), но обязательных аргументов у ее стандартного варианта два: имя файла блочного устройства и имя каталога. В результате выполнения этой команды файловая система, расположенная на указанном устройстве, подключается к системе таким образом, что ее содержимое заменяет собой содержимое заданного каталога (поэтому для монтирования обычно используют пустой каталог). Команда umount выполняет обратную операцию — отсоединяет файловую систему, после чего накопитель можно извлечь и положить на полку (на самом деле проблемы возникают почти исключительно с дискетами: CD-ROM, магнитно-оптический диск или Zip-диск, который забыли размонтировать, просто не удастся вытащить без помощи скрепки — он блокируется).
    продолжение
--PAGE_BREAK--Такие разные файлы
Осталось выяснить, что такое файл блочного устройства. Для этого следует рассказать о том, какие вообще «звери» встречаются в файловой системе. Очевидно, там есть обычные файлы и каталоги, но это далеко не все. Файлами с точки зрения Linux являются также:
символьные устройства; блочные устройства; именованные каналы (named pipes); гнезда (sockets); символьные ссылки (symlinks).
Все эти «звери» в чем-то похожи на обычные файлы, а в чем-то отличаются от них (во всяком случае, все они могут быть удалены системным вызовом unlink, что сближает их с обычными файлами и отдаляет от каталогов). Рассмотрим их по порядку.
Символьные и блочные устройства
Файлы символьных и блочных устройств создаются с помощью программы mknod и соответствуют внешним устройствам, а также псевдоустройствам, таким как знаменитое пустое устройство /dev/null (такое, при попытке чтения из которого сразу же сообщается о достижении конца файла и при записи в которое никогда не происходит переполнения — точный аналог NUL в DOS/Windows).

Устройства нумеруются двумя целыми числами — старшим (major number) и младшим (minor number). Первое из них соответствует типу устройства (например, для устройств, подключенных к первому IDE-контроллеру, оно равно 3, для подключенных ко второму — 22 и т. д.), а второе — конкретному устройству (например, для мастер-диска, подключенного к первому IDE-контроллеру, оно равно 0, для первого раздела на этом диске — 1 и т. д.). При этом символьные и блочные устройства нумеруются независимо.

Число 30Ah в поле «положение» информации о файлах /usr/bin/unzip и /usr/bin/zipinfo на рис. 1 и 2 обозначает как раз номер устройства: 3 — это первый IDE-диск, а 0A — его десятый раздел.

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

Многие устройства имеют дополнительные характеристики: скажем, на консоли (виртуальной) IBM PC есть три лампочки — Num Lock, Caps Lock и Scroll Lock, — а последовательный порт может передавать данные с различной скоростью. Как правило, программы в Linux работают просто с файлами, никак или почти никак не учитывая особенности того или иного конкретного устройства. Если же программа должна их учитывать, она осуществляет управление соответствующими параметрами через системный вызов ioctl, позволяющий, например, зажечь Num Lock или изменить громкость звука. В основном использование ioctl сводится к управлению конфигурацией (отсюда и название — I/O ConTroL, т. е. управление вводом-выводом).

Основной недостаток описанной схемы в том, что она плохо масштабируется: различных устройств существует великое множество, и поскольку всякое устройство, потенциально подключаемое к компьютеру, должно получить номер (а многие — несколько номеров), этих самых номеров явно не хватает. Кроме того, хотя в каталоге /dev, где традиционно хранятся файлы устройств, представлен, разумеется, далеко не весь спектр аппаратуры (только для SCSI-устройств потребовалось бы завести не одну тысячу файлов), он все-таки обычно содержит более тысячи файлов, и лишь очень малая их часть соответствует устройствам (или псевдоустройствам), реально присутствующим в системе.

Эта проблема была осознана достаточно давно, и уже предложено несколько вариантов ее решения. Однако самым распространенным остается пока стандартный подход, когда все файлы устройств создаются вручную программой mknod. Мне представляется наиболее удачным вариант с использованием специальной файловой системы devfs, монтируемой в каталог /dev, в которой специальные файлы устройств создаются и уничтожаются автоматически по мере надобности (именно так настроен компьютер, где сейчас пишутся эти строки).
Именованные каналы
Канал — это простейшее, но очень удобное и широко применяемое средство обмена информацией между процессами. Все, что один процесс помещает в канал (буквально — в «трубу»), другой может оттуда прочитать. Если два процесса, обменивающиеся информацией, порождены одним и тем же родительским процессом (а так чаще всего и происходит), канал может быть неименованным. В противном случае требуется создать именованный канал, что можно сделать с помощью программы mkfifo. При этом собственно файл именованного канала участвует только в инициации обмена данными.
Гнезда
Вообще гнезда (и взаимодействие программ при помощи гнезд) играют очень важную роль во всех Unix-системах, включая и Linux: они являются ключевым понятием TCP/IP и соответственно на них целиком строится Internet. Однако c точки зрения файловой системы гнезда практически неотличимы от именованных каналов: это просто метки, позволяющие связать несколько программ. После того как связь установлена, общение программ происходит без участия файла гнезда: данные передаются ядром ОС непосредственно от одной программы к другой*.
Символические ссылки
Символическая ссылка — относительно новое понятие в Unix. Это особый файл с информацией о том, что требуемый файл в действительности находится в другом месте, и о том, где именно его искать. Например, файл /usr/bin/gzip представляет собой символическую ссылку, указывающую на файл /bin/gzip; благодаря ей можно использовать /bin/gzip, обращаясь к нему как к /usr/bin/gzip. Близким аналогом символических ссылок являются ярлыки Windows 9X и NT 4.0, но ярлыки интерпретируются Проводником Windows, а символические ссылки — непосредственно ядром ОС.

В отличие от обычной, или, как еще говорят во избежание путаницы, жесткой ссылки, символическая ссылка может указывать на файл из другой файловой системы (например, находящийся на другом диске). Заметим, что при создании жесткой ссылки мы получаем два равноправных объекта (при удалении файла /usr/bin/unzip файл /usr/bin/zipinfo будет работать по-прежнему), а вот символическая ссылка при удалении (или переименовании/перемещении) объекта, на который она указывает, «провисает» и становится неработоспособной.

Во второй части статьи мы рассмотрим права доступа к файлам и работу Linux с другими файловыми системами.

* В настоящее время гнезда, создаваемые с помощью соответствующих специальных файлов, так же как и именованные каналы, не позволяют связывать программы, работающие на разных машинах сети.
    продолжение
--PAGE_BREAK--Монтирование.
Как уже было сказано, монтирование файловых систем выполняется командой mount, а их размонтирование — командой umount. Исключение составляет корневая файловая система*, которая обслуживается отдельно и до всех остальных систем. Действительно, только при ее наличии становятся доступными и сама команда mount, и каталог /dev, где находятся файлы устройств, и подкаталоги для монтирования. Чтобы файловые системы можно было монтировать при запуске ОС и размонтировать при ее остановке, используются два файла, которые традиционно размещаются в подкаталоге /etc: /etc/fstab и /etc/mtab.

Файл /etc/fstab содержит список файловых систем, которые могут быть смонтированы. Конечно, необходимые параметры всегда можно указать при вызове команды mount, но гораздо удобнее, когда они извлекаются из файла. Содержимое моего файла /etc/fstab показано на рис. 3.



Рис. 3. Пример файла fstab

Каждой точке монтирования в нем соответствует одна строка, состоящая из шести полей: название устройства, на котором расположена файловая система, точка монтирования, тип файловой системы, параметры монтирования, «уровень дампа» и порядковый номер файловой системы для программы fsck. Рассмотрим эти поля по порядку.

Название устройства

Чаще всего в этом поле задается имя блочного устройства, на котором размещена файловая система, но так бывает не всегда: для файловой системы procfs, дающей доступ к внутренним структурам ядра, здесь может находиться любой текст (в примере — слово none), для сетевой файловой системы указывается имя сервера и подкаталога на нем и т.д. Даже для обычных файловых систем данное поле иногда содержит нечто отличное от имени устройства: скажем, в трех последних строках моего файла /etc/fstab это имена файлов с образами дисков CD-ROM. Кроме того, разрешается указать вместо имени устройства метку диска или его серийный номер, например:

LABEL=temp /tmp ext2 defaults 1 2 UUID=3a30d6b4-08a5-11d3-91c3-e1fc5550af17 /usr ext2 defaults 1 2

Эта возможность редко применяется на машинах с обычной конфигурацией аппаратуры, но очень полезна в случае, когда к компьютеру подключены десятки дисков через ряд SCSI-контроллеров или интерфейс Firewire, либо когда на нем происходит работа со множеством сменных накопителей и имеется несколько устройств для их чтения.

Точка монтирования

Поле со вполне, казалось бы, очевидным значением, но пара маленьких подвохов все-таки имеется. Во-первых, при автоматическом монтировании файловые системы монтируются в том порядке, в каком они перечислены в /etc/fstab, и если, например, файловая система /home у вас находится на отдельном диске, а /home/ftp — еще на одном диске, то строка с описанием /home должна стоять в /etc/fstab до строки с описанием /home/ftp. Во-вторых, для раздела (или файла) подкачки данное поле никак не используется, и его содержимое может быть любым — лишь бы оно вообще присутствовало (этого требует формат файла).

Тип файловой системы

Уж здесь-то какие могут быть подвохи? Их и нет. Почти. Можно задать в этом поле значение auto, и тогда команда mount попытается сама определить тип файловой системы. Это не так уж замечательно, как может показаться: тип файловой системы определяется путем проверки так называемого «магического числа», которая срабатывает далеко не всегда, а кроме того, перебираются только файловые системы, которые поддерживаются ядром в данный момент (они перечислены в файле /proc/filesystems). Иначе говоря, если у вас имеется дискета с файловой системой minix, а ни одного раздела с этой системой не смонтировано, то при явном задании типа в память будет загружен модуль с файловой системой minix и дискета смонтируется, а при указании типа auto этого, скорее всего, не произойдет и смонтировать дискету не удастся.

Параметры монтирования

Это поле обладает одной весьма неприятной особенностью: часть задаваемых в нем параметров интерпретируется командой mount, а часть — ядром системы. Параметры, интерпретируемые ядром, различны в зависимости от файловой системы и версии ядра (некоторые из них будут рассмотрены в разделе, посвященном «иностранным» файловым системам), а команда mount интерпретирует следующие параметры:
async — весь ввод-вывод осуществляется асинхронно; atime — изменять параметр «время доступа» при обращении к файлам (по умолчанию); auto — система может быть смонтирована при автоматическом монтировании; defaults — установки по умолчанию: rw + suid + dev + exec + auto + nouser + async; dev — система может содержать файлы блочных и символьных устройств; exec — она может содержать исполняемые файлы; loop — для размещения системы можно использовать обычный файл (стандартно файловые системы размещаются на устройствах, к каковым обычные файлы не относятся, но если указать параметр loop, программа mount находит свободное loop-устройство, «связывает» с ним с помощью программы losetup заданный файл и передает имя этого устройства системному вызову mount; именно так монтируются образы CD-ROM в трех последних строках моего файла fstab); noatime, noauto, nodev, noexec, nosuid, nouser — параметры, противоположные по значению соответствующим параметрам без «no-»; remount — повторно смонтировать уже смонтированную файловую систему (например, чтобы сменить параметры монтирования); ro — смонтировать файловую систему только для чтения; rw — смонтировать файловую систему для чтения и записи (установка по умолчанию); suid — разрешить интерпретацию битов SUID и SGID (подробнее мы рассмотрим их в разделе, посвященном правам доступа); sync — весь ввод-вывод осуществляется синхронно; user — обычный пользователь (не суперпользователь) наделяется правом монтировать и размонтировать данную файловую систему; этот параметр влечет за собой noexec, nosuid и nodev, если после него явно не указано exec, dev или suid.
«Уровень дампа»

Это поле — самое мистическое в /etc/fstab. Оно используется программой dump, предназначенной для создания резервных копий. Если файловая система должна участвовать в процессе резервного копирования, то здесь должно стоять число 1, если нет — 0 (в действительности возможны и другие значения, но чтобы объяснить их смысл, пришлось бы вникать в тонкости работы программы dump).

Порядковый номер файловой системы для программы fsck

Перед автоматическим монтированием во время загрузки ОС файловая система тестируется программой fsck, которая проверяет ее целостность и, если необходимо, исправляет простейшие ошибки. Чтобы ускорить этот процесс, можно запустить fsck параллельно для нескольких файловых систем. Однако параллельно обрабатываемые системы должны находиться на разных дисках, иначе вместо ускорения обработки мы получим замедление, ибо диск будет непрерывно получать запросы на чтение разных его участков. Значение, установленное в данном поле, позволяет влиять на последовательность проверки: если присвоить файловым системам одинаковые номера, они будут проверяться одновременно. Системы, для которых этот параметр установлен в 0, не проверяются вообще. Для корневой файловой системы его значение несущественно.

Если в файле /etc/fstab имеется строка, относящаяся к данной файловой системе, то при вызове для нее программы mount можно опустить параметры монтирования, название устройства или точку монтирования. Этот файл используется также в графических оболочках, таких как KDE, где монтирование файловой системы сводится к щелчку мышью.

Программа amd и особая файловая система autofs позволяют сделать так, чтобы файловая система автоматически монтировалась при «заходе» в специальный каталог и размонтировалась через некоторое время после того, как последняя программа перестанет использовать файлы из нее. Однако это достаточно рискованно при работе с обычными дисководами гибких дисков: если по ошибке вынуть дискету из дисковода в тот момент, когда она смонтирована, можно серъезно разрушить файловую систему на ней.

В файле /etc/mtab хранится информация о том, какие файловые системы сейчас смонтированы и с какими параметрами монтирования это было сделано. Данные о смонтированных файловых системах содержатся также в файле /proc/mounts (и там они точнее, поскольку отображают соответствующую внутреннюю таблицу ядра), но параметров, с которыми эти системы были смонтированы, в нем нет, поскольку они в ядре не хранятся (а те из них, которые интерпретируются программой mount, вообще не доходят до ядра), поэтому /etc/mtab также находит применение.
    продолжение
--PAGE_BREAK--Права доступа
Теперь, когда мы выяснили, какие объекты встречаются в файловой системе, полезно вспомнить, что Linux, подобно другим Unix-системам, является многопользовательской ОС, а значит, доступ к файлам должен ограничиваться.
Пользователи и группы
Стандартная система прав доступа в Linux, пришедшая все из тех же далеких 70-х, весьма проста и логична, хотя и не всегда удобна*. Ее базовые понятия — пользователь и группа. Каждый зарегистрированный в системе пользователь получает уникальный номер-идентификатор. Кроме того, он должен входить хотя бы в одну группу, которая является для него «главной», и может входить в другие — «дополнительные» (supplementary groups). Все группы также перенумерованы. Файл всегда связан с определенным пользователем — своим владельцем — и с определенной группой, т. е. у него есть UID (User ID, идентификатор пользователя) и GID (Group ID, идентификатор группы). Изменять права доступа к файлу разрешено только его владельцу. Изменить владельца файла может суперпользователь, группу — суперпользователь или владелец файла (см. рис. 1).



Рис. 1. Midnight Commander: изменение владельца и группы файла с помощью команды chown

Программа, выполняющаяся в системе, всегда запускается от имени какого-то пользователя и какой-то группы (обычно — основной группы этого пользователя), но связь процессов с пользователями и группами организована сложнее: здесь различаются идентификатор для доступа к файловой системе (FSUID — File System access User ID, FSGID — File System access Group ID) и эффективный идентификатор (EUID — Effective User ID, EGID — Effective Group ID), а при доступе к файлам учитываются еще и полномочия (capabilities), присвоенные самому процессу. Соответствующие механизмы мы разберем, когда будем рассматривать управление процессами.

При создании файл получает UID, совпадающий с FSUID процесса, который его создает, и, как правило, GID, совпадающий с FSGID этого процесса; об исключении будет сказано чуть ниже.
Атрибуты доступа
Права доступа приписываются узлу файла. Каждому файлу сопоставлены три набора атрибутов доступа: для владельца, для группы и для всех остальных.

Атрибуты определяют, что разрешено делать с данным файлом данной категории пользователей. Каков же набор возможных операций в Linux (и — шире — в Unix)? Оказывается, их всего три: чтение, запись и выполнение. Как же, спросите вы, быть, например, с созданием и удалением файлов? И как можно выполнить каталог?

При создании файла (или еще одного имени для уже существующего файла) модифицируется не сам файл, а каталог, в котором появляются новые ссылки на узлы. Удаление же файла, как мы помним, заключается в удалении ссылки. Таким образом, право на создание или удаление файла — это право на запись в каталог.

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

Помимо трех названных основных атрибутов доступа существуют дополнительные, используемые в особых случаях. Наиболее важные из них — SUID, SGID и SVTX.

Атрибуты SUID и SGID существенны при запуске программы на выполнение: они требуют, чтобы программа выполнялась не от имени запустившего ее пользователя (группы), а от имени владельца (группы) того файла, в котором она находится. Выражаясь более формально, если файл программы имеет атрибут SUID (SGID), то FSUID и EUID (FSGID и EGID) соответствующего процесса не наследуются от процесса, запустившего его, а совпадают с UID (GID) файла. Благодаря этому «рядовые» пользователи получают, например, возможность запустить системную программу, которая создает свои рабочие файлы в закрытых для них каталогах.

Кроме того, если процесс создает файл в каталоге, имеющем атрибут SGID, то файл получает GID не по FSGID процесса, а по GID каталога. Это удобно для коллективной работы: все файлы и подкаталоги в каталоге автоматически оказываются принадлежащими одной и той же группе, хотя создавать их могут разные пользователи.

Атрибут SVTX (называемый также sticky bit, т. е. бит-липучка) в эпоху молодости Unix определял, нужно ли выгружать программу из памяти по окончании ее выполнения, однако сейчас от ручного управления выгрузкой отказались. Зато SVTX приобрел новое значение применительно к каталогам: из каталога, имеющего этот атрибут, ссылку на файл может удалить только владелец файла. SVTX применяется в первую очередь в каталоге /tmp, где хранятся временные файлы: создать там файл может любой пользователь системы, а удалить — только тот, кто его создал (и, разумеется, суперпользователь).
Запись прав доступа
Существуют две стандартных формы записи прав доступа — символьная и восьмеричная. Символьная представляет собой цепочку из десяти знаков, первый из которых не относится собственно к правам, а обозначает тип файла (‘-’ — обычный файл, ‘d’ — каталог, ‘c’ — символьное устройство, ‘b’ — блочное устройство, ‘p’ — именованный канал, ‘s’ — «гнездо», ‘l’ — символическая ссылка). Далее следуют три последовательности, каждая из трех символов, соответствующие правам пользователя, группы и всех остальных. Наличие права на чтение обозначается буквой ‘r’, на запись — ‘w’ на выполнение — ‘x’, отсутствие какого-либо права — знаком ‘-’ в соответствующей позиции. Наличие атрибута SUID (SGID) обозначается буквой ‘S’ в позиции права на выполнение для владельца (группы), если выполнение не разрешено, и буквой ‘s’, если разрешено. SVTX записывается соответственно буквой ‘T’ или ‘t’ в позиции права на выполнение для «посторонней публики».

Восьмеричная запись — шестизначное число, первые два знака которого обозначают тип файла и довольно часто опускаются, третий — атрибуты GUID (4), SGID (2) и SVTX (1), а оставшиеся три — соответственно права владельца, группы и всех остальных: чтение — 4, запись — 2, выполнение — 1.

Например, стандартный набор прав доступа для каталога /tmp в символьной форме выглядит как drwxrwxrwt, а в восьмеричной как 041777 (это каталог; чтение, запись и поиск разрешены всем; установлен атрибут SVTX). А набор прав -r-S—xw—, или 102412, будет означать, что это обычный файл, владельцу разрешается читать его, но не выполнять и не изменять, пользователям из группы файла (за исключением владельца) — выполнять (причем во время работы программа получит права владельца файла), но не читать и не изменять, а всем остальным — изменять, но не читать и не выполнять. Пример, конечно, условный: трудно вообразить себе ситуацию, в которой действительно потребовалось бы назначить файлу подобные права доступа.

А вот несколько более реалистичный пример. Вообразим себе, что среди пользователей некой машины имеется группа «писателей», которые сочиняют коллективную монографию, и группа «читателей», которые по ходу написания читают ее и высказывают свои замечания. Пользователям, не входящим ни в одну из этих групп, материалы должны быть недоступны. На первый взгляд кажется, что здесь мы натыкаемся на ограниченность системы прав Linux: у файла (или каталога) может быть только один GID.

Однако выход достаточно прост: если сформировать группы так, чтобы список «писателей» был включен в список группы «читателей» (что вполне логично — только в анекдоте чукча может быть писателем, не будучи читателем), то нужного результата можно добиться с помощью иерархии из двух каталогов:

d—-r-x—- /readers UID=0,

GID=

d—-rwsr-x /readers/writers

UID=0, GID=

Все файлы размещаются в каталоге /readers/writers. Модифицировать их разрешено «писателям», а читать всем, но реально добраться до этого каталога смогут только те, у кого есть право на выполнение каталога /readers, т. е. «читатели».

Большинство программ создают файлы с разрешением на чтение и запись для всех пользователей, а каталоги — с разрешением на чтение, запись и поиск для всех пользователей. Этот исходный набор атрибутов логически складывается с «пользовательской маской» — user file-creation mask, сокращенно umask, которая обычно ограничивает доступ. Так, для описанного только что примера значение umask должно быть u=rwx,g=rwx,o=rx, т. е. у владельца и группы остается полный набор прав, а всем остальным запрещается запись. В восьмеричном виде оно запишется как 002 (первый знак — ограничения для владельца, второй — для группы, третий — для остальных, запрещение чтения — 4, записи — 2, выполнения — 1).

В дальнейшем владелец файла может изменить права доступа к нему командой chmod, а если он не хочет разбираться с запутанным синтаксисом команды, то с помощью какой-либо из многочисленных программ-оболочек (например, Midnight Commander — см. рис. 2).



Рис. 2. Midnight Commander: изменение прав доступа к файлу

Новые пользователи часто не могут понять, в чем разница между атрибутами «время модификации» (modification time) и «время изменения» (change time). В действительности первое соответствует тому моменту, когда в последний раз изменялось содержимое файла, а второе — тому, когда изменялись его характеристики, например ссылки или права доступа.
    продолжение
--PAGE_BREAK--Об именах
Вернемся теперь к именам файлов. Как уже говорилось, они не очень важны с точки зрения Linux и вообще Unix: например, существует функция системной библиотеки, которая создает и сразу же «удаляет» файл со случайным именем, после чего возвращает ссылку на него. Ставший безымянным файл продолжает существовать до окончания использования, так что программа получает в свое распоряжение файл, к которому нельзя обычным образом обратиться извне. Однако с точки зрения пользователя имя все-таки представляет собой довольно существенный параметр файла.

Какие же ограничения накладываются на имена файлов? Их немного — поразительно немного для людей, работавших ранее с другими ОС:
имя файла не должно содержать символов ‘\0’ (символ с кодом 0) и ‘/’; имя файла не должно быть длиннее 255 символов; полный путь к файлу должен быть не длиннее 4096 символов.
Это все. Причем есть способ добраться и до файла, путь к которому оказался слишком длинным; мы расскажем о нем в связи с процессами.

Имена файлов считаются одинаковыми, если они совпадают побитно, т. е. разница между большими и маленькими буквами существенна. Тем самым, проблема поддержки разных кодировок отпадает: ядру системы неважно, какой набор символов использовался для записи имени — Latin 1, koi8-u, UTF-8 или Big5, лишь бы в нем не встречались два «запрещенных» символа. Иногда это приводит к курьезам. Например, в результате загрузки с помощью программы Minicom файла C:\WINDOWS\ COMMAND\EDIT.COM вполне может образоваться файл с именем из 27 символов — «C:\WINDOWS\ COMMAND\EDIT.COM» (первый символ — ‘C’, второй — ‘:’, третий — ‘\\’ и т. д).

К сожалению, допустимость имени с точки зрения ядра системы еще не гарантирует того, что с ним смогут работать прикладные программы. Среди последних немало даже таких, которые вообще не признают символов с ненулевым старшим битом (а значит, «не понимают» русских букв). В этом смысле русификация Linux является противоположностью русификации DOS: в DOS основной проблемой было «научить» систему вводить и отображать русские буквы (особенно в именах файлов); когда это было сделано, большинство программ начали совершенно свободно работать с кириллицей. В Linux же поддержка русских букв имелась в ядре системы «с самого начала» (их ввод и вывод на системной консоли был обеспечен хотя и не «с самого начала», но также очень и очень давно), а все необходимое для русификации (за исключением, пожалуй, масштабируемых шрифтов) входит в комплект любого современного дистрибутива. Однако программы зачастую отказываются работать с русскими буквами, и их нужно либо специально настраивать (как, например, bash), либо обманывать с помощью «шаманских» приемов (так приходится поступать со StarOffice).
«Чужие» файловые системы
Поговорим теперь немного о поддерживаемых в Linux «чужих» файловых системах. В действительности общих правил работы с ними не существует — слишком уж они разнообразны, — поэтому ограничимся тем, что рассмотрим по отдельности несколько наиболее важных.
Файловые системы Unix
Начать удобнее с систем, которые нельзя считать в полном смысле слова «чужими», поскольку они также применяются в ОС семейства Unix и обслуживаются ядром Linux наравне со стандартной Ext2 fs. ЭтоMinix fs (Minix, Xenix), System V/Coherent fs (System V, Xenix) иUFS (FreeBSD, NetBSD, OpenBSD, SunOS/Solaris, NextStep, OpenStep).

Во всех названных системах (включая, естественно, и Ext2 fs) пользователи и группы представлены только идентификаторами (UID, GID); фактически ядро ОС ничего не знает об их именах. Следовательно, человек, сумевший подключить ваш диск к машине, на которой он является суперпользователем, получит возможность читать и модифицировать любую информацию на диске, не зная пароля суперпользователя вашей системы. (В ряде случаев для этого достаточно быть суперпользователем одной из установленных на машине ОС, причем не обязательно Linux — подойдет даже Windows 95, если только злоумышленнику удастся получить из нее доступ к вашему диску.)

Поэтому обычно не имеет смысла ограничивать права доступа к файлам на сменных носителях информации. Чтобы защитить хранящиеся там данные, лучше их зашифровать. О прозрачном шифровании файлов в Linux можно узнать по адресам www.kerneli.org/ и tcfs.dia.unisa.it/. В дальнейшем поддержка шифрования, видимо, будет встроена в ядро Linux (в связи с изменением законодательства США, касающегося экспорта криптотехнологий, такая возможность теперь появилась), однако неясно, произойдет ли это уже в версии 2.4.
FAT
Наиболее распространенная файловая система — это, конечно же, FAT (в Linux она называется msdos). Множество пророков множество раз предсказывали ей смерть, и все же ее модификации (VFAT, FAT32) до сих пор служат основной файловой системой в Windows 9x, а для дискет даже Windows NT не предлагает ничего другого. Оригинальная версия FAT, сохранявшаяся практически неизменной от MS-DOS 2.0 до MS-DOS 6.22, крайне проста: вся информация о файле хранится в каталоге, и для доступа к ней используется имя файла, построенное по так называемой «формуле 8+3», т. е. состоящее из собственно имени длиной до 8 символов и расширения длиной до 3 символов, разделенных точкой.

Большие и маленькие буквы в именах файлов не различаются: при всех операциях с файлами используются большие буквы (именно это свойство породило известные проблемы с русскими буквами в именах файлов, продержавшиеся вплоть до появления русифицированной версии Windows 3.1). У каждого файла хранится время последней модификации (с точностью до 2 с) и могут быть установлены атрибуты Read Only (только для чтения), Archive (архивный), Hidden (скрытый) и System (системный).

При монтировании диска с FAT атрибут Read Only отображается в соответствующий атрибут файловой системы Linux, остальные же игнорируются, поскольку не имеют аналога. В результате файлы с атрибутом Read Only получают набор прав доступа r-xr-xr-x, а все прочие — rwxrwxrwx. Чтобы как-то еще ограничить права доступа, следует задать среди параметров монтирования нужное значение umask, а чтобы при этом предоставить привилегии определенным пользователям, — указать соответствующие UID и GID. Можно также просто разрешить пользователям самим монтировать разделы, но это не очень удобно, поскольку нельзя смонтировать один и тот же раздел дважды.
    продолжение
--PAGE_BREAK--VFAT и FAT32
Файловая система VFAT впервые появилась в Windows NT, а широкое распространение получила после выхода Windows 95: это усовершенствованная версия FAT, в которой разрешены длинные имена файлов. FAT32, введенная в Windows 95 OSR2 и поддерживаемая в Windows 98, отличается от VFAT лишь количественными параметрами: она допускает меньший размер кластеров и больший размер дисков, не ограничивает число файлов в корневом каталоге и т. д. Поэтому в Linux работа с VFAT и FAT32 происходит совершенно одинаково; для FAT32 нет даже отдельного драйвера. С этим связан забавный момент: RedHat Linux 5.1 поддерживает FAT32, но единственный способ узнать об этом — попытаться смонтировать соответствующий раздел и убедиться, что он монтируется. В документации FAT32 не упоминается.

Появившиеся в VFAT длинные имена сделали работу с файлами более удобной, однако породили ряд проблем. Во-первых, VFAT сохраняет в именах разницу между большими и маленькими буквами, но для доступа к файлам разрешает использовать любые их комбинации. Во-вторых, что более существенно, у каждого файла в VFAT есть два имени — длинное и короткое. При просмотре диска Linux показывает в смонтированном разделе VFAT только длинные имена, но по короткому имени доступ к файлу также будет предоставлен, а при попытке создать новый файл, имя которого совпадет с коротким именем существующего файла, вы получите сообщение о том, что такой файл уже есть, — точно так же, как и в Windows.

Далее, если в VFAT дать файлу имя, удовлетворяющее ограничениям FAT и состоящее из символов стандартного набора ASCII, то Windows 95 и NT будут считать, что он имеет только короткое имя. При этом с точки зрения Windows 95 такое имя будет состоять только из больших букв, а с точки зрения Windows NT — только из маленьких. Linux здесь выбирает строну NT (по историческим причинам). В большинстве случаев все это не имеет значения; сложности возникают лишь при работе с программой установки RedHat Linux и ее производными, которые отличаются повышенной чувствительностью к названиям каталогов с исходными файлами.

И, наконец, длинные имена файлов записываются в кодировке Unicode. Поэтому при монтировании разделов с VFAT необходимо задавать правила их преобразования, что делается с помощью параметра iocharset; в наших условиях обычно указывают iocharset=koi8-r. Если длинное имя содержит символы, не имеющие соответствия в текущем iocharset, к файлу обратиться невозможно. Чтобы получить доступ ко всем файлам (правда, имена их примут неудобочитаемый вид), нужно вместо iocharset указать uni_xlate= true или utf8= true (подробнее см. /usr/src/linux/Documentation/filesystems/vfat.txt).

Набор символов для коротких имен задается параметром codepage. Когда Windows настроена на русский язык, для коротких имен применяется CP 866 (кодировка DOS), поэтому следует указать codepage=cp866.
ISO-9660
ISO-9660 используется на CD-ROM**. Ее исходная версия не поддерживает прав доступа и символических ссылок; для имен файлов допустима длина до 32 символов, причем большие и маленькие буквы не различаются. Кроме того, если имя файла не укладывается в схему 8+3, то файл не будет доступен из MS-DOS, а если оно состоит из маленьких букв (некоторые программы позволяют так сделать), то и из Windows NT.

Ограничения ISO-9660 преодолеваются в ее расширенном варианте, который называется Rock Ridge. С ним работают различные Unix-системы, включая Linux, но ни в одной из версий Windows он не поддерживается. Зато для Windows 95 разработано альтернативное расширение — Joliet, обеспечивающее только поддержку длинных имен файлов (в формате Unicode); с ним Linux также умеет работать.

При монтировании CD-ROM разрешается отключить Rock Ridge (Joliet) и, если не используется RockRidge, указать UID, GID и umask. Для дисков с Joliet задается iocharset; можно указать и utf8, но не uni_xlate. Все эти параметры имеют то же значение, что и для (V)FAT.
NTFS
О работе с NTFS, к сожалению, можно сказать мало утешительного. Это исключительно сложная и гибкая файловая система, а открытая документация по ней практически отсутствует. Два названных свойства и определяют границы поддержки NTFS в Linux. Обеспечивается работа с версиями вплоть до NTFS4 (Windows NT 4.0). Версия же NTFS5 (Windows 2000 Pro) не поддерживается, и неизвестно, когда появится ее поддержка (если появится вообще).

Даже для тех версий, с которыми Linux работает, доступ предоставляется только к основной секции файла: в NTFS файл может иметь произвольное число секций, аналогичных «вилкам» (forks) MacOS (но в MacOS у каждого файла ровно две секции — «вилка данных» и «вилка ресурсов»). А запись в раздел NTFS возможна только в особом экспериментальном режиме, перед включением которого рекомендуется подготовиться к восстановлению диска после полной потери данных, — и это не просто громкое предупреждение.

Вся система прав доступа NTFS в Linux игнорируется, и доступ к файлам регулируется так же, как для FAT. Правда, если указать параметр posix=yes, можно будет увидеть все имена файлов — и короткие, и длинные. Заодно это позволит увидеть файлы с именами, отличающимися только регистром символов. Откуда они берутся? Дело в том, что в Windows NT есть подсистема POSIX, внутри которой различаются большие и маленькие буквы, есть возможность создавать жесткие ссылки и т. д. Она иногда используется при переносе программ из Unix в Windows NT.

В Linux поддерживается еще много файловых систем (HFS, HPFS и др.), но они реже встречаются на практике. Сетевые файловые системы — coda, smbfs, nсpfs и nfs.

Ниже приведены характеристики и особенности некоторых современных файловых систем, поддерживаемых Linux.
Таблица 1. Некоторые современные файловые системы
Название

Максимальный размер файловой системы

Размеры блоков

Максимальный размер файла

XFS

18 тыс. Пбайт

от 512 байт до 64 Кбайт

9 тыс. Пбайт

JFS

блок на 512 байт/4 Пбайт

512/1024/ 2048/4096 байт

512 Тбайт

блок на 4 Кбайт32 Пбайт

4 Пбайт

ReiserFS

4 гигаблоков

До 64 Кбайт (сейчас фиксированы 4 Кбайт)

4 Гбайт

ext3fs

4 Тбайт

1 Кбайт — 4 Кбайт

2 Гбайт


    продолжение
--PAGE_BREAK--Таблица 2. Особенности современных файловых систем
Метод/ Файловая система

Управление свободными блоками

Экстенты для свободного пространства

B-деревья для элементов каталогов

B-деревья для адресации блоков файлов

Экстенты для адресации блоков файлов

Данные внутри inode (небольшие файлы)

Данные симво-льных ссылок внутри inode

Элементы каталогов внутри inode (неболь-шие каталоги)

XFS

B-деревья, индексированные по смещению и по размеру

Да

Да

Да

Да

Да

Да

Да

JFS

Дерево+ Binary Buddy (1)

Нет

Да

Да

Да

Нет

Да

До 8

ReiserFS (2)

На основе битовой карты

Пока не поддерживается

Как поддерево основного дерева файловой системы

Внутри основного дерева файловой системы

Будет реализовано в версии 4

(3)

(3)

(3)

ext3fs

ext3fs не является файловой системой, созданной с нуля; она базируется на ext2fs, поэтому не поддерживает ни один из перечисленных выше методов; ext3fs предоставляет ext2fs поддержку журналирования, в то же время сохраняя обратную совместимость.
Примечания JFS использует иной подход к организации дерева блоков. Структура представляет собой дерево, где концевые узлы являются фрагментами битовой карты, а не непрерывными областями. Binary Buddy — это метод, используемый для управления и объединения вместе последовательных групп свободных логических блоков с целью формирования группы большего размера. Как уже было отмечено при обсуждении метода битовой карты, каждый бит в карте соответствует логическому блоку на диске. Значение бита «1» означает, что блок занят, «0» — свободен. Фрагменты битовой карты, каждый из которых содержит 32 бита, могут быть интерпретированы как шестнадцатеричные числа. Так, значение «FFFFFFFF» указывает, что блоки, соответствующие битам этого фрагмента битовой карты, все заняты. Наконец, за счет использования этого числа резервирования и другой информации JFS создает дерево, в котором можно быстро найти группу последовательных блоков определенного размера. Эта файловая система базируется на B*деревьях (усовершенствованная версия B+дерева). Основное различие сводится к тому, что каждый объект файловой системы размещается внутри общего B*дерева. Это значит, что для каждого каталога не создается своего дерева, но каждый каталог имеет поддерево в основном дереве файловой системы. Такой подход предполагает, что в ReiserFS применяются более сложные методы индексирования. Еще одно важное отличие состоит в том, что ReiserFS не использует экстенты, хотя в перспективе они будут поддерживаться. ReiserFS помещает каждый объект файловой системы внутри B*дерева. Эти объекты, каталоги, блоки файлов, атрибуты файлов, ссылки и так далее — все поддерживаются внутри одного и того же дерева. Для получения значения ключевого поля, необходимого для организации элементов внутри B-дерева, используются методы хеширования. Их несомненным достоинством является тот факт, что за счет изменения применяемого метода хеширования можно изменить способ, каким файловая система организует элементы и их относительное положение внутри дерева. Журнальные файловые системы (journal file system). За последние годы Linux приобрела немало новых возможностей и применяется во многих гетерогенных средах. Linux работает на микроконтроллерах, применяется в маршрутизаторах, служит для поддержки аппаратных ускорителей трехмерной графики, поддерживает многоэкранную среду Xfree. Все это важные функции для конечных пользователей. Но немало сделано и для удовлетворения требований, предъявляемых к серверам, в особенности, с момента перехода на ядро Linux 2.2.x.
Благодаря широкой поддержке отрасли и усилиям, предпринимаемым сторонниками свободно распространяемых программ, Linux приобрела важные черты, присущие коммерческим версиям Unix и других ОС для крупных серверов. Одна из таких черт — поддержка файловых систем, способных работать с большими разделами жестких дисков, легко масштабироваться на многие тысячи файлов, быстро восстанавливаться после сбоя, поддерживать более высокую производительность ввода/вывода, эффективно работать с файлами самого разного размера, противостоять внутренней и внешней фрагментации и даже предоставлять новые функции, которые не поддерживаются ни в одной из более традиционных файловых систем.

В этом разделе мы познакомимся с так называемыми журнальными файловыми системами (journal file system): JFS, Ext3 и ReiserFS .
    продолжение
--PAGE_BREAK--Глоссарий Внутренняя фрагментация
Логический блок — минимальная единица дискового пространства, которую резервирует файловая система посредством системных вызовов. Если размер файла меньше числа байт в логическом блоке, то на диске он все равно будет занимать один блок. Таким образом, если длина конкретного файла не делится нацело на число байт в логическом блоке (размер файла MOD размер блока є0), то файловая система будет вынуждена резервировать новый блок, который останется незаполненным до конца, что приводит к нерациональному использованию дискового пространства. Такая излишняя трата пространства на диске называется внутренней фрагментацией. Чем больше размер логического блока, тем больше будет и внутренняя фрагментация.
Внешняя фрагментация
Внешняя фрагментация возникает в ситуации, когда логические блоки конкретного файла разбросаны по всему диску, что приводит к замедлению операций с данным файлом, поскольку требует большего числа движений считывающей головки диска.
Экстент
Экстент (непрерывная область на диске) представляет собой последовательность логических блоков. Механизм экстентов используется несколькими файловыми системами и ядрами баз данных. Описатель экстента обычно состоит из трех полей: beginning, extent size, offset, где beginning («начало») — это адрес блока, с которого начинается экстент, extent size («размер экстента») — это количество блоков, а offset («сдвиг») — это смещение первого байта экстента относительно начала файла.

Экстент позволяет более эффективно расходовать дисковое пространство, поскольку все блоки в нем располагаются последовательно. Кроме того, при чтении файла выполняется меньше движений считывающей головки. Использование экстентов сокращает негативный эффект внешней фрагментации, поскольку большее число блоков хранится последовательно. В том случае, если приложению необходим экстент, близкий по размеру к логическому блоку, преимущества от его применения сводятся к минимуму, поскольку в итоге создается множество небольших экстентов, которые будут играть роль обычных логических блоков. Рост производительности при использовании экстентов достигается за счет уменьшения перемещений между секторами и сокращения числа промахов при обращении к кэш-памяти диска.

Экстенты позволяют эффективно организовывать большие цепочки свободных, последовательно расположенных блоков. Они помогают сократить объем дискового пространства, требуемый для отслеживания свободных блоков, позволяя тем самым увеличить производительность.
B+деревья
B+деревья широко используются в индексных структурах баз данных, обеспечивая быстрый и масштабируемый доступ к записям. Название «B+дерево» — сокращение от Balanced Tree («сбалансированное дерево»). Знак «+» указывает на то, что это модифицированная версия «исходного» B-дерева; она содержит указатели, которые провязывают между собой листья дерева, что помогает последовательному доступу.

B+деревья состоят из узлов двух различных типов: промежуточные узлы и концевые узлы (листья). Все узлы содержат в себе множества пар (ключ, указатель), упорядоченные по значению ключа в порядке возрастания. Указатели промежуточных узлов служат для ссылки на другие указатели промежуточных или концевых узлов, указатели концевых узлов — непосредственно на информацию. Ключ применяется для организации информации внутри B+дерева. В базах данных каждая запись имеет поле ключа, по значению которого различают записи одного и того же типа. B-деревья используют ключ для построения индекса записей баз данных, который позволяет сократить время доступа к ним. Сравнивая текущий ключ с ключом искомого узла, программа находит требуемую информацию.

Чтобы найти определенную запись, необходимо сделать следующее. Предположим, что мы ищем запись с определенным ключом — «K». Поиск следует начинать с корневого узла, а затем последовательно сканировать ключи, хранящиеся внутри. Узел сканируется до тех пор, пока не найден ключ со значением больше «K». Затем переходим к узлу (промежуточному или конечному, пока не известно точно, к какому), на который ссылается соответствующий указатель. После этого, если этот узел является промежуточным, операция повторяется. Наконец, найден конечный узел, который последовательно сканируется до тех пор, пока не найден требуемый ключ «K». Поскольку, для того чтобы найти нужный ключ, требуется извлечь меньшее число блоков, этот метод поиска имеет меньший уровень сложности, чем последовательное сканирование, при котором, в самом худшем случае, пришлось бы просмотреть все элементы.
UNIX File System
UFS — название файловой системы, использовавшейся в SCO Unix, System V и некоторых других ранних вариантах Unix. Ядро Linux включает факультативную поддержку UFS. Большинство диалектов Unix по-прежнему использует UFS, хотя и с небольшими специфическими модификациями.
Virtual File System
VFS — специальный уровень в ядре, который предоставляет унифицированный API-интерфейс файловых служб, не зависящий от того, в какой именно файловой системе размещается файл. Все реализации файловой системы (vfat, ext2fs, jfs и т.д.) должны предоставлять определенные функции VFS, чтобы их можно было использовать в Linux. Этот уровень абстракции дает пользовательским приложениям возможность работать с множеством различных файловых систем, в том числе, и с коммерчески распространяемыми продуктами.
Журнал Что такое журнальная файловая система
Общеизвестно, что представляет собой кэш-память — буфер, зарезервированный в быстрой памяти и предназначенный для ускорения операций ввода/вывода. Такого рода буфер часто используется в файловых системах (его называют дисковым кэшем) и в базах данных для увеличения общей производительности. Проблема возникает в том случае, если в системе произошел сбой прежде, чем буферы были записаны на диск; в таком случае после перезагрузки системы она будет находиться в противоречивом состоянии. Представьте себе, что файл был удален из кэша, но остался на жестком диске. Вот почему базы данных и файловые системы должны иметь возможность возвращать систему в непротиворечивое состояние. За долгие годы совершенствования баз данных были созданы способы, позволяющие быстро восстанавливать их, однако, время восстановления файловых систем и, более конкретно, UFS-подобных систем увеличивается по мере роста размеров файловой системы. Утилита восстановления fsck для ext2fs должна просканировать раздел диска целиком, чтобы вернуть файловую систему обратно в непротиворечивое состояние. Из-за того, что эта задача требует очень больших затрат времени в случае крупных серверов с сотнями гигабайт, а иногда и терабайт данных, говорить о высоком уровне готовности подобных систем не приходится. Именно это стало основной причиной создания для файловых систем технологии, подобной технологии восстановления баз данных, в силу чего и появились журнальные файловые системы.
    продолжение
--PAGE_BREAK--