Теперь мы опишем наиболее популярную дисковую файловую систему Linux - ext2. Первый выпуск Linux использовал файловую систему MINIX 1, которая имела короткие имена файлов и максимальный размер файла 64 Мбайт. Файловая система MINIX 1 была в итоге заменена первой расширенной файловой системой ext, которая позволяла использовать более длинные имена файлов и более крупные размеры файлов. Вследствие своей низкой эффективности (в смысле производительности) система ext была заменена своей последовательницей ext2, которая до сих пор широко используется.

Дисковый раздел с ext2 содержит файловую систему с показанной на рис. 10.17 компоновкой. Блок 0 не используется системой Linux и содержит код загрузки компьютера. Следом за блоком 0 дисковый раздел разделен на группы блоков (без учета границ цилиндров диска). Каждая группа организована следующим образом.

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

В двух битовых массивах ведется учет свободных блоков и свободных i-узлов (это тоже унаследовано из файловой системы MINIX 1 и отличает ее от большинства файловых систем UNIX, в которых для свободных блоков используется список). Размер каждого битового массива равен одному блоку. При размере блока 1 Кбайт такая схема ограничивает размер группы блоков 8192 блоками и 8192 i-узлами. Первое число является реальным ограничением, а второе - практически нет. При блоках размером 4 Кбайт числа в четыре раза больше.

Затем располагаются сами i-узлы. Они нумеруются от 1 до некоторого максимума. Размер каждого i-узла - 128 байт, и описывает он ровно один файл. i-узел содержит учетную информацию (в том числе всю возвращаемую вызовом stat, который просто берет ее из i-узла), а также достаточное количество информации для определения местоположения всех дисковых блоков, которые содержат данные файла.

Следом за i-узлами идут блоки данных. Здесь хранятся все файлы и каталоги. Если файл или каталог состоит более чем из одного блока, то эти блоки не обязаны быть непрерывными на диске. В действительности блоки большого файла, скорее всего, будут разбросаны по всему диску.

Соответствующие каталогам i-узлы разбросаны по всем группам дисковых блоков. Ext2 пытается расположить обычные файлы в той же самой группе блоков, что и родительский каталог, а файлы данных - в том же блоке, что и i-узел исходного файла (при условии, что там имеется достаточно места). Эта идея была позаимствована из файловой системы Berkeley Fast File System (McKusick et al., 1984). Битовые массивы используются для того, чтобы принимать быстрые решения относительно выделения

места для новых данных файловой системы.

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

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

Каталог позволяет использовать имена файлов длиной до 255 символов (рис. 10.18). Каждый каталог состоит из некоторого количества дисковых блоков (чтобы каталог можно было записать на диск атомарно). В каталоге элементы для файлов и каталогов находятся в несортированном порядке (каждый элемент непосредственно следует за предыдущим). Элементы не могут пересекать границы блоков, поэтому в конце каждого дискового блока обычно имеется некоторое количество неиспользуемых байтов.

Каждая запись каталога на рис. 10.18 состоит из четырех полей фиксированной длины и одного поля переменной длины. Первое поле представляет собой номер i-узла, равный 19 для файла colossal, 42 для файла voluminous и 88 для каталога bigdir. Следом идет поле rec_len, сообщающее размер всей записи каталога в байтах (возможно, вместе с дополнительными байтами-заполнителями после имени). Это поле необходимо, чтобы найти следующую запись (в том случае, когда имя файла дополнено неизвестным количеством байтов). На рисунке это поле обозначено стрелкой. Затем располагается поле типа файл, каталог и т. д. Последнее поле фиксированной длины содержит длину имени файла в байтах (8, 10 и 6 для данного примера). Наконец, идет само имя файла, заканчивающееся нулевым байтом и дополненное до 32-битной границы. За ним могут следовать дополнительные байты-заполнители.

На рис. 10.18, б показан тот же самый каталог после того, как элемент для voluminous был удален. Все, что при этом делается в каталоге, - увеличивается число в поле размера записи предыдущего файла colossal, а байты записи каталога для удаленного файла voluminous превращаются в заполнители первой записи. Впоследствии эти байты могут использоваться для записи при создании нового файла.

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

Например, чтобы найти файл, указанный абсолютным путем (таким, как /usr/ast/file), необходимо выполнить следующие шаги. Прежде всего система находит корневой каталог, который обычно использует i-узел с номером 2 (особенно когда i-узел с номером 1 зарезервирован для работы с плохими блоками). Она помещает в кэш элементов каталога соответствующий элемент (для будущих поисков корневого каталога). Затем она ищет в корневом каталоге строку «usr», чтобы получить номер i-узла для каталога /usr (который также вносится в кэш элементов каталога). Этот i-узел затем читается, и из него извлекаются дисковые блоки, так что можно читать каталог /usr и искать в нем строку «ast». После того как соответствующий элемент найден, из него можно определить номер i-узла для каталога /usr/ast. Имея этот номер i-узла, его можно прочитать и найти блоки каталога. И наконец, мы ищем «file» и находим номер его i-узла. Таким образом, использование относительного пути не только более удобно для пользователя, но и сокращает количество работы для системы.

Если файл имеется в наличии, то система извлекает номер i-узла и использует его как индекс таблицы i-узлов (на диске) для поиска соответствующего i-узла и считывания его в память. Этот i-узел помещается в таблицу i-узлов (i-node table) - структуру данных ядра, которая содержит все i-узлы для открытых в данный момент файлов и каталогов. Формат элементов i-узлов должен содержать (как минимум) все поля, которые возвращает системный вызов stat, чтобы вызов stat мог работать (см. табл. 10.10). В табл. 10.13 показаны некоторые из полей структуры i-узла, поддерживаемой в файловой системе Linux. Реальная структура i-узла содержит гораздо больше полей, поскольку эта же структура используется для представления каталогов, устройств и прочих специальных файлов. Структура i-узла содержит также зарезервированные для будущего использования поля. История показала, что неиспользованные биты недолго остаются без дела.

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

n = read(fd, buffer, nbytes);

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

Идея состоит в том, чтобы начать с этого дескриптора файла и закончить соответствующим Ьузлом. Давайте рассмотрим одну вполне возможную схему: поместим указатель на Ьузел в таблицу дескрипторов файлов. Несмотря на простоту, данный метод (к сожалению) не работает. Проблема заключается в следующем. С каждым дескриптором файла должен быть связан указатель в файле, определяющий тот байт в файле, с которого начнется следующая операция чтения или записи. Где следует хранить этот указатель? Один вариант состоит в размещении его в таблице Ьузлов. Однако такой подход не сможет работать, если несколько не связанных друг с другом процессов одновременно откроют один и тот же файл, поскольку у каждого процесса должен быть собственный указатель.

Второй вариант решения заключается в размещении указателя в таблице дескрипторов файлов. При этом каждый открывающий файл процесс имеет собственную позицию в файле. К сожалению, такая схема также не работает, но причина неудачи в данном случае не столь очевидна и имеет отношение к природе совместного использования файлов в системе Linux. Рассмотрим сценарий оболочки 5, состоящий из двух команд (р1 и р2), которые должны выполняться по очереди. Если сценарий вызывается командной строкой

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

Когда оболочка запустит процесс р1, файл x будет сначала пустым, поэтому команда р1 просто начнет запись в файл в позиции 0. Однако когда р1 закончит свою работу, потребуется некий механизм, который гарантирует, что процесс р2 увидит в качестве начальной позиции не 0 (а именно так и произойдет, если позицию в файле хранить в таблице дескрипторов файлов), а то значение, на котором остановился pi.

То, как это делается, показано на рис. 10.19. Фокус состоит в том, чтобы ввести новую таблицу - таблицу описания открытых файлов (open file description table) - между таблицей дескрипторов файлов и таблицей i-узлов и хранить в ней указатель в файле (а также бит чтения/записи). На рисунке родительским процессом является оболочка, а дочерним сначала является процесс pi, а затем процесс p2. Когда оболочка создает процесс pi, то его пользовательская структура (включая таблицу дескрипторов файлов) представляет собой точную копию такой же структуры оболочки, поэтому обе они содержат указатели на одну и ту же таблицу описания открытых файлов. Когда процессpi завершает свою работу, дескриптор файла оболочки продолжает указывать на таблицу описания открытых файлов, в которой содержится позиция процесса p1 в файле. Когда теперь оболочка создает процесс p2, то новый дочерний процесс автоматически наследует позицию в файле, при этом ни новый процесс, ни оболочка не обязаны знать текущее значение этой позиции.

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

Итак (возвращаясь к проблеме выполнения чтения read), мы показали, как определяются позиция в файле и i-узел. I-узел содержит дисковые адреса первых 12 блоков файла. Если позиция в файле попадает в его первые 12 блоков, то считывается нужный блок файла и данные копируются пользователю. Для файлов, длина которых превышает 12 блоков, в i-узле содержится дисковый адрес одинарного косвенного блока (single indirect block) (рис. 10.19). Этот блок содержит дисковые адреса дополнительных дисковых блоков. Например, если размер блока составляет 1 Кбайт, а дисковый адрес занимает 4 байта, то одинарный косвенный блок может хранить до 256 дисковых адресов. Такая схема позволяет поддержать файлы размером до 268 Кбайт.

Как и в любой файловой системе UNIX, в составе ext2 можно выделить следующие составляющие:

− блоки и группы блоков;

− индексный дескриптор;

− суперблок.

Всё пространство раздела диска разбивается на блоки фиксированного размера, кратные размеру сектора: 1024, 2048, 4096 или 8192 байт. Размер блока указывается при создании файловой системы на разделе диска. Меньший размер блока позволяет сэкономить место на жёстком диске, но также ограничивает максимальный размер файловой системы. Все блоки имеют порядковые номера. С целью уменьшения фрагментации и количества перемещений головок жёсткого диска при чтении больших массивов данных блоки объединяются в группы блоков.

Базовым понятием файловой системы является индексный дескриптор, или inode (англ. information node). Это специальная структура, которая содержит информацию об атрибутах и физическом расположении файла. Индексные дескрипторы объединены в таблицу, которая содержится в начале каждой группы блоков.

Рисунок 10 - Обобщенная структурная схема ФС ext2

Суперблок - основной элемент файловой системы ext2. Он содержит общую информацию о файловой системе:

общее число блоков и индексных дескрипторов в файловой системе,

число свободных блоков и индексных дескрипторов в файловой системе,

размер блока файловой системы,

количество блоков и индексных дескрипторов в группе блоков,

размер индексного дескриптора,

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

Суперблок находится в 1024 байтах от начала раздела. От целостности суперблока напрямую зависит работоспособность файловой системы. Операционная система создаёт несколько резервных копий суперблока на случай повреждения раздела. В следующем блоке после суперблока располагается глобальная дескрипторная таблица - описание групп блоков, представляющее собой массив, содержащий общую информацию обо всех группах блоков раздела.

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

номер блока в битовой карте блоков,

номер блока в битовой карте inode,

номер блока в таблице inode,

число свободных блоков в группе,

число индексных дескрипторов, содержащих каталоги.

Битовая карта блоков - это структура, каждый бит которой показывает, отведён ли соответствующий ему блок какому-либо файлу. Если бит равен 1, то блок занят. Аналогичную функцию выполняет битовая карта индексных дескрипторов, которая показывает, какие именно индексные дескрипторы заняты, а какие нет. Ядро Linux, используя число индексных дескрипторов, содержащих каталоги, пытается равномерно распределить inode каталогов по группам, а inode файлов старается по возможности переместить в группу с родительским каталогом. Все оставшееся место, обозначенное в таблице как данные, отводится для хранения файлов.

Файловая система ext2 использует следующую схему адресации блоков файла. Для хранения адреса файла выделено 15 полей, каждое из которых состоит из 4 байт. Если файл умещается в 12 блоков, то номера соответствующих кластеров непосредственно перечисляются в первых двенадцати полях адреса. Если размер файла превышает 12 блоков, то следующее поле содержит адрес кластера, в котором могут быть расположены номера следующих блоков файла. Таким образом, 13-е поле используется для косвенной адресации.

При максимальном размере блока в 4096 байт кластер, соответствующий 13-му полю, может содержать до 1024 номеров следующих блоков файла. Если размер файла превышает 12+1024 блоков, то используется 14-е поле, в котором находится адрес кластера, содержащего 1024 номеров кластеров, каждый из которых ссылается на 1024 блока файла. Здесь применяется уже двойная косвенная адресация. И наконец, если файл включает более 12+1024+1048576 блоков, то используется последнее 15-е поле для тройной косвенной адресации.

Данная система адресации позволяет при максимальном размере блока в 4096 байт иметь файлы, размер которых превышает 2 ТБ.

ext3 или ext3fs - журналируемая файловая система, используемая в операционных системах на ядре Linux. Основана на ФС ext2.

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

Стандартом предусмотрено три режима журналирования:

writeback: в журнал записываются только метаданные файловой системы, то есть информация о её изменении. Не может гарантировать целостности данных, но уже заметно сокращает время проверки по сравнению с ext2;

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

journal: полное журналирование как метаданных ФС, так и пользовательских данных. Самый медленный, но и самый безопасный режим; может гарантировать целостность данных при хранении журнала на отдельном разделе (а лучше - на отдельном жёстком диске).

Файловая система ext3 может поддерживать файлы размером до 1 ТБ. С Linux-ядром 2.4 объём файловой системы ограничен максимальным размером блочного устройства, что составляет 2 терабайта. В Linux 2.6 (для 32-разрядных процессоров) максимальный размер блочных устройств составляет 16 ТБ, однако ext3 поддерживает только до 4 ТБ.

ext4 - файловая система, основанная на ext3 и совместимая с ней (прямо и обратно). Отличается от ext3 поддержкой extent"ов, групп смежных физических блоков, управляемых как единое целое; повышенной скоростью проверки целостности и рядом других усовершенствований.

Новые возможности ext4 (в сравнении с ext3):

Использование экстентов. В файловой системе ext3 адресация данных выполнялась традиционным образом, поблочно. Такой способ адресации становится менее эффективным с ростом размера файлов. Экстенты позволяют адресовать большое количество (до 128 MB) последовательно идущих блоков одним дескриптором. До 4х указателей на экстенты может размещаться непосредственно в inode, что достаточно для файлов маленького и среднего размера.

48-битные номера блоков. При размере блока 4K это позволяет адресовать до одного экзабайта (2 48 *4KB = 2 50 *1KB = 2 60 B = 1 EB).

Выделение блоков группами (multiblock allocation). Файловая система хранит не только информацию о местоположении свободных блоков, но и количество свободных блоков, идущих друг за другом. При выделении места файловая система находит такой фрагмент, в который данные могут быть записаны без фрагментации. Это снижает уровень фрагментации файловой системы в целом.

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

Превышен лимит в 32000 каталогов.

Резервирование inode"ов при создании каталога (directory inodes reservation). При создании каталога резервируется несколько inode"ов. Впоследствии, при создании файлов в этом каталоге сначала используются зарезервированные inode"ы, и если таких не осталось, выполняется обычная процедура.

Размер inode. Размер inode (по умолчанию) увеличен с 128 до 256 байтов. Это дало возможность реализовать те преимущества, которые перечислены ниже.

Временные метки с наносекундной точностью (nanosecond timestamps). Более высокая точность времён, хранящихся в inode. Диапазон хранящихся времён тоже расширен: если раньше верхней границей хранимого времени было 18 января 2038 года, то теперь это 25 апреля 2514 года.

Версия inode. В inode появился номер, который увеличивается при каждом изменении inode файла.

Хранение расширенных атрибутов в inode (EA in inode). Хранение расширенных атрибутов, таких как ACL, атрибутов SELinux и прочих, позволяет повысить производительность. Атрибуты, для которых недостаточно места в inode, хранятся в отдельном блоке размером 4KB.

Контрольное суммирование в журнале (Journal checksumming). Контрольные суммы журнальных транзакций. Позволяют лучше найти и (иногда) исправить ошибки при проверке целостности системы после сбоя.

Предварительное выделение (persistent preallocation). Сейчас для того, чтобы приложению гарантированно занять место в файловой системе, оно заполняет его нулями. В ext4 появилась возможность зарезервировать множество блоков для записи и не тратить на инициализацию лишнее время. Если приложение попробует прочитать данные, оно получит сообщение о том, что они не проинициализированы. Таким образом, несанкционированно прочитать удалённые данные не получится.

Дефрагментация без размонтирования (online Defragmentation).

Неинициализированные блоки (uninitialised groups). Позволяет ускорить проверку файловой системы. Блоки, отмеченные как неиспользуемые, проверяются группами, и детальная проверка производится, только если проверка группы показала, что внутри есть повреждения.

Лекция 12.

Тема: Каталоговые системы

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

Например, в Ms-Dos и Windows каталоги образуют древовидную структуру, а в UNIX – сетевую. В общем случае вычислительная система может иметь несколько дисковых устройств, даже в ПК всегда имеется несколько дисков: гибкий, винчестер, CD-ROM (DVD). Как организовать хранение файлов в этом случае?

Рис. Каталоговые системы

Первое решение состоит в том, что на каждом из устройств размещается автономная файловая система, т.е. файлы, находящиеся на этом устройстве, описываются деревом каталогов, никак не связанным с деревьями каталогов на других устройствах. В таком случае для однозначной идентификации файла пользователь вместе с составным символьным именем файла должен указывать идентификатор логического устройства. Примером такого автономного существования может служить MS-DOS, Windows 95/98/Me/XP.

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

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

Файловая система, расположенная на системном диске, называется корневой. Для связи иерархий файлов в корневой файловой системе выбирается некоторый существующий каталог, в данном примере – каталог loc. После выполнения монтирования выбранный каталог loc становится корневым каталогом второй файловой системы. Через этот каталог монтируемая файловая система подсоединяется как поддерево к общему дереву.

Рис. Монтирование

Атрибут

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

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

Значения атрибутов файлов могут содержаться в каталогах, как это сделано, например, в MS-DOS (рис. 7.7). Другим вариантом является размещение атрибутов в специальных таблицах, в этом случае в каталогах содержатся ссылки на эти таблицы.

Рис. 7. Атрибуты файлов MS DOS

ext2 (также называется как ext2fs ) - Second Extended File System (Вторая Расширенная Файловая Система) представляет собой файловую систему, построенную на ядре Linux. Создателем и разработчиком ext2 является Реми Кард. Файловая система ext2 была построена им взамен старой, предыдущей версии - ext.

По таким показателям как скорость и производительность данная файловая система может служить эталоном. Об этом говорят результаты тестов производительности файловых систем. К примеру, в испытаниях на скорость последовательного чтения и записи, которые проводил технический центр Dell, файловая система ext2 превосходит ext3 , и уступает в скорости чтения лишь более современной ext4 .

Главным недостатком ext2 является то, что она не является журналируемой файловой системой. Однако, этот недостаток был устранен в следующей файловой системе - ext3.

ext2 используется на флеш-картах и твердотельных накопителях (SSD), поскольку отсутствие журналирования является преимуществом при работе с накопителями с ограничениями на количество циклов записи.

История создания ext2

Во времена бурного развития системы Linux, в ней применялась файловая система ОС Minix. Она отличалась довольно высокой стабильностью, но при этом была 16-разрядной. Вследствие этого, в ней существовало жесткое ограничение в 64 Mb на раздел. Кроме того, имелось ограничение и на максимальную длину имени файла, которое составляло 14 символов.

Эти ограничения в совокупности послужили причиной для разработки «расширенной файловой системы» (отсюда и термин «Extended File System» ). На нее возлагалась задача по решению двух ключевых проблем Minix. Новая файловая система была обнародована в апреле 1992 года. Это была Ext, она расширила ограничения на размер файла до 2 гигабайт и установила предельную длину имени файла в 255 символов.

Однако, несмотря на успех новой файловой системы, тем не менее, оставалось еще довольно много нерешенных проблем. К примеру, отсутствовала поддержка раздельного доступа, не было временных меток модификации данных. Необходимость решения данных задач и послужила мотивом для создания следующей версии расширенной файловой системы ext2 («Second Extended File System» ). ext2 была разработана в январе 1993 года, в ней также были реализованы соответствующие стандарту POSIX списки контроля доступа ACL и расширенные атрибуты файлов.

Логическая организация ext2

Граф иерархии каталогов ext2 представлен в виде сети. Это связано с тем, что один файл может входить сразу в несколько каталогов.

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

Что касается символа NULL, то ограничения связаны с представлением строк в языке Си, в случае с символом слеш, все заключается в том, что он используются как разделительный символ между каталогами.

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

Атрибуты ext2:

• тип и права доступа к файлу,
• владелец, группа доступа,
• информация по разрешенным операциям,
• время создания, дата последнего доступа, дата последнего изменения и время последнего удаления,
• текущий размер файла,
• спецификация файла:

• обычный файл,
• каталог,
• файл байт-ориентированного устройства,
• файл блочно-ориентированного устройства,
• именованный канал,
• символическая ссылка,

• число занимаемых блоков,
• прочие

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

Физическая организация ext2

Структура дискового раздела

В составе ext2 можно выделить следующее:

• блоки и группы блоков;
• индексный дескриптор;
• суперблок.

Все пространство раздела диска разбивается на блоки фиксированного размера, блоки кратны размеру сектора (1024, 2048, 4096 или 8192 байт). Размер блока указывается при создании файловой системы на разделе диска. Всем блокам присвоены порядковые номера. Для уменьшения фрагментации и количества перемещений головок жесткого диска при чтении больших массивов данных блоки объединяются в группы.

Базовым понятием файловой системы является индексный дескриптор (также называют inode - information node ). Это специальная структура, содержащая информацию об атрибутах и физическом расположении файла. Индексные декрипторы объединены в таблицу, содержащуюся в начале каждой группы блоков. Суперблок — основной элемент файловой системы ext2. В нем содержится общая информация о файловой системе. Суперблок расположен в 1024 байтах от начала раздела. Целостность суперблока определяет работоспособность файловой системы. ОС создает несколько резервных копий суперблока - на случай повреждения раздела. В следующем блоке после суперблока располагается глобальная дескрипторная таблица — описание групп блоков в виде массива с общей информацией обо всех группах блоков.

Группа блоков

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

Битовая карта блоков — это система, в которой каждый бит информирует, отведен ли соответствующий ему блок какому-либо файлу. Если бит равен 1, то блок занят. Аналогичную функцию выполняет битовая карта индексных дескрипторов: она показывает, какие именно индексные дескрипторы заняты, а какие нет. Ядро Linux старается равномерно распределить inode каталогов по группам, а inode файлов - переместить в группу с родительским каталогом. Все оставшееся место, фигурирующее в таблице в качестве данных, отводится для хранения файлов.

Система адресации данных

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

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

При максимальном размере блока в 4096 байт кластер, соответствующий 13-му полю, может содержать до 1024 номеров следующих блоков файла. Если размер файла превышает 12+1024 блоков, то используется 14-е поле, в котором находится адрес кластера, содержащего 1024 номеров кластеров, каждый из которых ссылается на 1024 блока файла. Здесь применяется уже двойная косвенная адресация. А если файл включает более 12+1024+1048576 блоков, то применяется последнее 15-е поле для тройной косвенной адресации.

Такая система адресации позволяет при максимальном размере блока в 4096 байт иметь файлы, размером свыше 2 TB.

Файловая система (англ. file system) - порядок, определяющий способ организации, хранения и именования данных на носителях информации ИТ – оборудования (использующего для многократной записи и хранения информации портативные флеш-карты памяти в портативных электронных устройствах: цифровых фотоаппаратах, мобильных телефонах и т. д) и компьютерной техники. Она определяет формат содержимого и физического хранения информации, которую принято группировать в виде файлов. Конкретная файловая система определяет размер имени файла (папки), максимальный возможный размер файла и раздела, набор атрибутов файла. Некоторые файловые системы предоставляют сервисные возможности, например, разграничение доступа или шифрование файлов.

Задачи файловой системы

Основные функции любой файловой системы нацелены на решение следующих задач:

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

программный интерфейс работы с файлами для приложений;

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

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

Файловая система - это основная структура, используемая компьютером для упорядочения информации на жестком диске. При установке нового жесткого диска его необходимо разбить на разделы и отформатировать под определенную файловую систему, после чего на нем можно хранить данные и программы. В Windows существует три возможных варианта файловой системы: NTFS , FAT32 и редко используемая устаревшая система FAT (также известная как FAT16).

NTFS является предпочтительной файловой системой для этой версии Windows. Она имеет множество преимуществ перед более ранней системой FAT32; ниже перечислены некоторые из них.

Способность автоматически восстанавливаться после некоторых ошибок диска (FAT32 не обладает такой способностью).
Улучшенная поддержка больших жестких дисков.
Более высокая степень безопасности. Возможно использование разрешений и шифрования для запрета пользовательского доступа к определенным файлам.

Файловая система FAT32 и редко применяемая система FAT использовались в предыдущих версиях Windows, в том числе в Windows 95, Windows 98 и Windows Millenium Edition. Файловая система FAT32 не обеспечивает уровня безопасности, предоставляемого NTFS, поэтому если на компьютере имеется раздел или том, отформатированный под FAT32, файлы на этом разделе видны любому пользователю, имеющему доступ к компьютеру. Файловая система FAT32 также имеет ограничения по размеру файлов. В этой версии Windows невозможно создать раздел FAT32 размером более 32Гб. Кроме того, раздел FAT32 не может содержать файл размером более 4Гб.

Основной причиной использования системы FAT32 может служить то, что на компьютере можно будет запустить как Windows 95, Windows 98 или Windows Millenium Edition, так и эту версию Windows (конфигурация с несколькими операционными системами). Для создания такой конфигурации необходимо установить предыдущую версию операционной системы на раздел, отформатированный под FAT32 или FAT, сделав его основным (основной раздел может содержать операционную систему). Другие разделы, доступ к которым осуществляется из предыдущих версий Windows, также должны быть отформатированы под FAT32. Более ранние версии Windows могут обращаться только к сетевым NTFS-разделам или томам. NTFS-разделы на локальном компьютере будут недоступны.

FAT – плюсы:

Для эффективной работы требуется немного оперативной памяти.
Быстрая работа с малыми и средними каталогами.
Диск совершает в среднем меньшее количество движений головок (в сравнении с NTFS).
Эффективная работа на медленных дисках.

FAT – минусы:

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

NTFS – плюсы:

Фрагментация файлов не имеет практически никаких последствий для самой файловой системы – работа фрагментированной системы ухудшается только с точки зрения доступа к самим данным файлов.
Сложность структуры каталогов и число файлов в одном каталоге также не чинит особых препятствий быстродействию.
Быстрый доступ к произвольному фрагменту файла (например, редактирование больших.wav файлов).
Очень быстрый доступ к маленьким файлам (несколько сотен байт) – весь файл находится в том же месте, где и системные данные (запись MFT).

NTFS – минусы:

Существенные требования к памяти системы (64 Мбайт – абсолютный минимум, лучше – больше).
Медленные диски и контроллеры без Bus Mastering сильно снижают быстродействие NTFS.
Работа с каталогами средних размеров затруднена тем, что они почти всегда фрагментированы.
Диск, долго работающий в заполненном на 80% – 90% состоянии, будет показывать крайне низкое быстродействие.

В качестве «родных» для Linux (то есть тех, на которые он может быть установлен и с которых способен стартовать) рассматриваются следующие файловые системы: ext2fs, ext3fs, ext4fs, ReiserFS, XFS, JFS. Именно они обычно и предлагаются на выбор при установке подавляющего большинства дистрибутивов. Конечно, существуют и способы установки Linux на файловые системы FAT/VFAT/FAT32, но это - только для тех медам и мсье, которые понимают толк в извращениях, и о них я говорить не буду.

Основными критериями при выборе файловой системы являются обычно надежность и быстродействие. В некоторых случаях приходится учитывать также фактор совместимости - в данном случае под ней понимается способность других операционок обращаться к той или иной файловой системе.
Начну рассмотрение с ReiserFS - потому что поводом к сочинению этой заметки послужил вопрос: а что следует считать маленькими файлами? Ведь общеизвестно, что именно эффективность работы с мелкими файлами является сильной стороной этой файловой системы.

Так вот, под мелкими файлами понимаются файлы размером меньше логического блока файловой системы, который в Linux в большинстве случаев равен четырем килобайтам, хотя и может задаваться при форматировании в некоторых пределах (зависящих от конкретной FS). Таких мелких файлов в любой Unix-подобной ОС - бессчетное количество. Типичным примером являются файлы, составляющие дерево портов FreeBSD, портежей Gentoo и тому подобных портообразных систем.
В большинстве файловых систем для таких мини файлов существует как свой inode (информационный узел, содержащий мета информацию о файле), так и блок данных, что приводит как к расходу дискового пространства, так и снижению быстродействия файловых операций. В частности, именно в этом причина катастрофической задумчивости файловой системы FreeBSD (как старой, UFS, так и новой, UFS2) при работе с собственной же системой портов.

В файловой системе ReiserFS в таких случаях отдельные блоки под данные не выделяются - она умудряется запихать данные файла непосредственно в область его же inode. За счет этого и дисковое пространство экономится, и быстродействие возрастает - буквально в несколько раз по сравнению со всеми прочими FS.
Такое обращение с мелкими файлами ReiserFS послужило причиной возникновения легенды о ее ненадежности. Действительно, при крахе файловой системы (то есть разрушении служебных областей) данные, размещенные совместно со своими inodes, вместе с ними же и пропадают - причем безвозвратно. Тогда как в тех файловых системах, где inodes и блоки данных всегда разобщены пространственно, последние теоретически можно восстановить. Так, для ext2/ext3 даже существуют средства, позволяющие это сделать.

Однако, как и всякая легенда, эта лишь производит впечатление достоверности. Во-первых, безвозвратная потеря данных относится лишь к очень маленьким файлам. Среди пользовательских таковых практически не бывает, а все прочие же легко восстанавливаются из дистрибутива.
Во-вторых, говоря о возможности восстановления данных из блоков, утративших привязку к своим inodes, я не случайно употребил слово «теоретическая». Потому что на практике это занятие чрезвычайно трудоемкое, не дающее гарантированного результата. Каждый, кому приходилось этим заниматься, согласится, что предаться ему можно только от полной безысходности. И это относится ко всем файловым системам Linux. Так что этим аспектом при выборе файловой системы можно пренебречь.

По суммарному быстродействию ReiserFS однозначно быстрее всех остальных журналируемых FS, а по некоторым показателям превосходит и ext2. С результатами сравнения скорости выполнения некоторых распространенных файловых файловых операций можно ознакомиться здесь.
А вот с совместимостью у ReiserFS дело обстоит несколько хуже. Доступ к ней из ОС семейства Windows, насколько мне известно, невозможен. В некоторых операционных системах семейства BSD (DragonFlyBSD, FreeBSD) реализована поддержка этой файловой системы, но в режиме только для чтения. Даже вероятность того, что произвольный Linux LiveCD прошлых лет не имеет поддержку ReiserFS, не нулевая.

И тут впору вспомнить об ext3fs. Преимущество ее вовсе не в большей надежности - это такая же легенда, как и неустойчивость ReiserFS. О случаях краха ext3fs я слышал не меньше, чем об аналогичных происшествиях с ReiserFS. Самому мне не удавалось порушить ни ту, ни другую. Разве что с ext2 получалось - но и то очень давно, во времена ядра 2.2 (или даже еще 2.0).

Нет, главное преимущество ext3fs в ее совместимости - она с гарантией будет прочитана любой Linux-системой. Например, при восстановлении с какого-нибудь древнего подручного LiveCD - ситуация, практически не столь уж невероятная, мне приходилось в нее попадать. Опять же, большинство BSD-систем легко понимают ext3fs (хотя и без журналирования). Для Windows также имеются, насколько я знаю, всякого рода драйверы и plug-ins к распространенным файловым менеджерам (типа Total Commander), обеспечивающие доступ к разделам с ext2fs/ext3fs.

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

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

Относительно XFS можно сказать следующее. В плане совместимости к ней относится все то же самое, что написано для ReiserFS - более того, до некоторого времени она не поддерживалась стандартным ядром Linux. С точки зрения быстродействия она XFS она также не блещет, выступая суммарно примерно на одном уровне с ext3fs. А на операции удаления файлов вообще демонстрирует удручающую медлительность.
По моим наблюдениям, использование XFS оправдывает себя при работе не просто с большими, а с очень большими файлами - каковыми являются фактически только образы DVD и видеофайлы.

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

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

Если предусматривается отдельный раздел под каталог /boot (а это рекомендуется при использовании загрузчика GRUB его разработчиками) - для него никакая другая файловая система, кроме ext2fs, не оправданна, какое-либо журналирование тут смысла не имеет. Наконец, если создается отдельный раздел под всякого рода мультимедийные материалы - тут можно подумать и о XFS.

Если же подойти к объяснению более методично

ext - на начальном этапе развития Linux была доминирующей система ext2 (расширенная файловая система, версия 2). С 2002 года ей на смену пришла система ext3, которая во многом совместима с ext2, но к тому же поддерживает функции журналирования, а при работе с версией ядра 2.6 и выше - и ACL. Максимальный размер файла составляет 2 Тбайт, максимальный размер файловой системы - 8 Тбайт. В конце 2008 года было официально заявлено о выпуске версии ext4, которая обладает обратной совместимостью с ext3, но многие функции внедрены более эффективно, чем ранее. Кроме того, максимальный размер файловой системы равен 1 Эбайт (1 048 576 Тбайт), и можно рассчитывать, что на какое-то время такого объема хватит. О reiser - система получила название от имени своего основателя - Ганса Рай-зера (Hans Reiser) и была первой системой с функциями журналирования, обращавшейся за данными к ядру Linux. Версия З.п в SUSE даже считалась стандартной в течение некоторого времени. Основные преимущества reiser в сравнении с ext3 - более высокая скорость работы и эффективность размещения при работе с мелкими файлами (а в файловой системе, как правило, большинство файлов мелкие). Со временем, правда, разработка reisefers приостановилась. Уже давно было заявлено о выходе версии 4, которая все еще не готова, а поддержка версии 3 прекратилась. О xfs - первоначально файловая система xfs разрабатывалась для рабочих станций фирмы SGI, функционировавших в операционной системе IRIX. Xfs особенно хороша для работы с крупными файлами, в частности идеально подходит для работы с потоковым видео. Система поддерживает квотирование и расширенные атрибуты (ACL).
jfs

jfs - a66peBHaTypaJFS расшифровывается «Журналируемая файловая система». Первоначально она была разработана для IBM, а затем адаптирована для Linux.Jfs никогда не пользовалась в Linux особым признанием и в настоящее время влачит жалкое существование, уступая другим файловым системам.
brtfs

brtfs - если на то будет воля ведущих разработчиков ядра, файловую систему brtfs в Linux ждет блестящее будущее. Эта система была разработана в Oracle с нуля. Она включает функции поддержки модуля отображения устройств (device-mapper) и RAID. Brtfs наиболее сходна с системой ZFS, разработанной компанией Sun. К ее самым интересным функциям относится проверка файловой системы на ходу, а также поддержка SSD (твердотельные диски - это жесткие диски, работающие на основе флеш-памяти). К сожалению, работа над brtfs в обозримом будущем не завершится. В Fedora, уже начиная с версии 11, предусмотрена возможность установки brtfs, но пользоваться ею я рекомендую только разработчикам файловых систем!
Не существует «быстрейшей» или «наилучшей» файловой системы - оценка зависит от того, для чего вы собираетесь использовать систему. Начинающим пользователям Linux, работающим с локальным компьютером, рекомендуется работать с ext3, а администраторам серверов - с ext4. Конечно, с ext4 скорость работы повыше, чем с ext3, но при этом в системе ext4 значительно хуже дело обстоит с надежностью данных - вы вполне можете потерять информацию при внезапном отключении системы.

Если вы установили на компьютере вторую UNIX-подобную операционную систему, то при обмене данными (из одной ОС в другую) вам пригодятся следующие файловые системы.

sysv - применяется в ОС SCO, Xenix и Coherent.

ufs - используется в FreeBSD, NetBSD, NextStep и SunOS. Linux может только считывать информацию из таких файловых систем, но не может вносить изменения в данные. Для доступа к сегментам с BSD дополнительно потребуется расширение BSD disklabel. Аналогичное расширение существует и для таблиц разбиения SunOS.

ZFS - это относительно новая система, разработанная Sun для Solaris. Поскольку код ZFS не соответствует лицензии GPL, ее нельзя интегрировать с ядром Linux. По этой причине Linux поддерживает эту файловую систему лишь опосредованно, через FUSE.
Windows, Mac OS X

Следующие файловые системы будут полезны при обмене информацией с MS DOS, Windows, OS/2 и Macintosh.

vfat - используется в Windows 9х/МЕ. Linux может считывать информацию из таких разделов и вносить в нее изменения. Драйверы системы vfat позволяют работать и со старыми файловыми системами MS DOS (8 + 3 символов).

ntfs - система применяется во всех современных версиях Windows: otNT и выше. Linux может считывать и изменять ее файлы.

hfs и hfsplus - эти файловые системы используются в компьютерах Apple. Linux может считывать и изменять ее файлы.

На CD и DVD с данными обычно используются собственные файловые системы.

iso9660 - файловая система для CD-ROM описана в стандарте ISO-9660, допускающем только короткие названия файлов. Длинные названия поддерживаются в различных операционных системах по-разному, с помощью многообразных несовместимых друг с другом расширений. Система Linux способна работать как с расширением Rockridge, обычным в UNIX, так и с расширением Joliet, разработанным Microsoft.

udf - этот формат (универсальный формат диска) появился и развился как наследник ISO 9660.

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

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

smbfs/cifs - помогают подключать сетевые каталоги Windows или Samba к дереву каталогов.

nfs - это важнейшая в UNIX сетевая файловая система.

coda - эта система очень напоминает NFS. В ней имеется множество дополнительных функций, но она не очень распространена.

ncpfs - работает на базе протокола ядра NetWare;oH используется Novell Netware.

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

В Linux существует несколько файловых систем, предназначенных не для сохранения данных на жестком диске (или другом носителе), а только для обмена информацией между ядром и пользовательскими программами.
devpts - эта файловая система обеспечивает доступ к псевдотерминалам (сокращенно - PTY) через /dev/pts/* в соответствии со спецификацией UNIX-98. (Псевдотерминалы эмулируют последовательный интерфейс. В системах UNIX/Linux такие интерфейсы используются эмуляторами терминалов, например xterm. При этом, как правило, применяются такие устройства, как /dev/ ttypn. В спецификации UNIX-98, напротив, определяются новые устройства. Более подробная информация сообщается в текстовом терминале H0WT0.)
proc и sysfs - файловая система proc служит для отображения служебной информации, касающейся управления ядром и процессами. В дополнение к этому файловая система sysfs строит взаимосвязи между ядром и оборудованием. Обе файловые системы подключаются на позициях /proc и /sys.
tmpfs - эта система построена на основе разделяемой памяти в соответствии с System V. Она обычно подключается на позиции /dev/shm и обеспечивает эффективный обмен информацией между двумя программами. В некоторых дистрибутивах (например, Ubuntu) каталоги /var/run и /var/lock также создаются с помощью файловой системы tmpfs. Файлы из этих каталогов применяются некоторыми сетевыми демонами для того, чтобы сохранять идентификационные номера процессов, а также информацию о доступе к файлам. Благодаря tmpfs эти данные теперь отражаются в RAM. Метод гарантирует высокую скорость, а также то, что после отключения компьютера в каталогах / var/run или /var/lock не останется никаких файлов.

usbfs - файловая система usbfs, начиная с версии ядра 2.6 и выше, дает информацию о подключенных USB-устройствах. Обычно она интегрирована в файловую систему proc. О поддержке USB-устройств в Linux.

Прочие файловые системы

auto - на самом деле файловой системы под таким названием не существует. Однако слово auto можно использовать в /etc/fstab или с командой mount для указания файловой системы. В таком случае Linux попытается самостоятельно распознать файловую систему. Этот метод работает с большинством важнейших файловых систем.
autofs, autofs4

autofs, autofs4 - это тоже не файловые системы, а расширения ядра, автоматически выполняющие команду mount для выбранных файловых систем. Если файловая система не используется в течение некоторого времени, то для нее автоматически выполняется команда umount. Этот метод удобен прежде всего в тех случаях, когда из многих NFS-каталогов одновременно активно используются всего несколько.

Для выполнения таких операций при запуске системы сценарий /etc/init.d/ autofs автоматически выполняет программу automount. Она конфигурируется с помощью файла /etc/auto.master. Соответствующие программы автоматически устанавливаются, например, в Red Hat и Fedora. В любом случае autofs активизируется только после конфигурации /etc/auto.master или /etc/auto.misc.
cramfs и squashfs

cramfs и squashfs - файловые системы Cram и Squash предназначены только для чтения. Они используются для того, чтобы «упаковать» как можно больше заархивированных файлов во флеш-память или ПЗУ (постоянное запоминающее устройство).

fuse - FUSE означает «Файловая система в пользовательском пространстве» (Filesystem in Userspace) и позволяет разрабатывать и использовать драйверы файловых систем вне ядра. Следовательно, FUSE всегда применяется с внешним драйвером файловой системы. FUSE работает, в частности, с драйвером NTFS ntfs-3g.

gfs и ocfs - Глобальная файловая система (Global File System) и Кластерная файловая система от Oracle (Oracle Cluster File System) позволяют строить гигантские сетевые файловые системы, к которым могут параллельно обращаться множество компьютеров в один и тот же момент.

jffs и yaffs - Журналируемая файловая система для флеш-носителей (Journaling Flash File System) и Альтернативная файловая система для флеш-носителей (Yet Another Flash File System) специально оптимизированы для работы с твердотельными дисками и флеш-носителями. С помощью специальных алгоритмов они пытаются равномерно использовать все ячейки памяти (технология «выравнивание износа»), чтобы избежать преждевременного отказа системы.
loop

loop - используется для работы с псевдоустройствами. Псевдоустройство (loopback device) - это адаптер, способный обращаться к обычному файлу как к блочному устройству. Благодаря ему в любом файле можно расположить любую файловую систему, а затем подключить ее к дереву каталогов с помощью mount. Отвечающая за это функция ядра - поддержка псевдоустройств - реализуется в модуле loop.

Существуют разнообразные способы применения псевдоустройств. В частности, они могут использоваться при создании дисков в оперативной памяти для начальной инициализации (Initial RAM disk) для GRUB или LILO, при реализации зашифрованных файловых систем или тестировании ISO-образов для CD.

Файловые системы носителей данных

Файловые системы
ISO 9660
Joliet расширение файловой системы ISO 9660.
Rock Ridge (RRIP, IEEE P1282) - расширение файловой системы ISO 9660, разработанное для хранения файловых атрибутов, используемых в операционных системах POSIX
Amiga Rock Ridge Extensions
El Torito
Apple ISO9660 Extensions
HFS, HFS+
Universal Disk Format cпецификация формата файловой системы, независимой от операционной системы для хранения файлов на оптических носителях. UDF является реализацией стандарта ISO/IEC 13346
Mount Rainier

Файловая система Linux — это чаще всего ext4. Она журналируема и позволяет удобно работать с данными при решении абсолютного большинства задач. Тем не менее существуют и другие. Основные типы файловых систем и принципы работы с ними будут рассмотрены в рамках данного материала.

Типы файловых систем Linux и их особенности

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

Файловая система может создаваться на любом устройстве: на диске или системной партиции.

Файловая система EXT2

EXT2 является в настоящее время устаревшей файловой системой, которая практически не используется в современных инсталяциях. основной недостаток — отсутствие журналирования что, соответственно, делает невозможным восстановление данных в случае сбоя. По прежнему применяется на портативных носителях информации, таких как USB. Журнал для них не требуется, поскольку занимает определенное пространство.

Также гарантирует максимальную скорость работы.

• для EXT2 максимальный размер файла -2 TB

Файловая система EXT3

Вытеснила EXT2, главной особенностью является появление журнала, является полностью обратно совместимой с EXT2 (EXT2 можно свободно конвертировать в EXT3). Сейчас встречается также редко, практически всегда используется EXT4.

Журнал — специальная область в памяти, в которую записывается информация обо всех изменениях

• для EXT3 максимальный размер файла -2 TB
• максимальный размер всех файлов — 32 TB
• в каждом каталоге может быть до 32 000 подкаталогов

При журналировании может быть три опции (указываются при создании файловой системы):

• journal – в журнал метаданные, а также сама информация
• ordered – опция по умолчанию, сохраняются только метаданные и после записи на диск
• writeback – также сохраняются только метаданные, можно выбрать сохранять их до записи на диск или после

Файловая система EXT4

Современная версия extended file system, чаще всего применяется именно она

• максимальный размер файла -2 TB 16 TB
• максимальный размер всех файлов — 1 EB (exabyte). 1 EB = 1024 PB (petabyte). 1 PB = 1024 TB (terabyte).
• в каждом каталоге может быть до 64 000 подкаталогов

В EXT4 ведение журнала можно выключить установив опцию data при монтировании в off

EXT как основная файловая система Linux и практика работы

Файловая система создается командой mk2fs

Нужная опция журналирования указывается при монтировании, например:

mount /dev/vdc /mnt/1 -t ext3 -o data=journal

Конвертирование из EXT2 Eв XT3

ReiserFS

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

Создать FS для устройства можно командой

XFS

XFS – журналируемая файловая система. Использует оперативную память для хранения информации, поэтому возможны потери данных — например, при отключении электропитания.

Чтобы использовать XFS в Ubuntu потребуется установить пакеты xfsprogs и xfsdump

vfat

Файловая система Linux, также существующая в Windows среде. Используется когда нужно организовать совместный досутп к определенным дискам и разделам клиентов с разными ОС. В других случаях использовать не рекомендуется поскольку при работе в Linux возможны сложности.