Что имеем - не храним,
Потерявши - плачем.
Народное

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

Сначала разберемся с самим жестким диском. Физически «жесткий диск» лишь в редких случаях действительно один диск. Обычно это пакет из нескольких (двусторонних) дисков. На стороны дисков ссылаются по номеру головки. Стороны разбиты на дорожки, называемые цилиндрами (по-видимому, со времен магнитных барабанов - когда магнитные диски не были плоскими, а напоминали шарманку). На дорожке располагаются секторы - минимальные порции данных, которые могут быть прочитаны или записаны. Тройка номеров головки, цилиндра и сектора и составляет физический адрес порции данных. Обычно с настоящими физическими адресами имеет дело лишь контроллер диска, извне диск может выглядеть несколько по-другому (происходит трансляция логического адреса в физический). Можно считать , что диск - это непрерывная линейная последовательность секторов. Некоторый фрагмент этой последовательности может быть выделен как раздел (partition) или том. Этот раздел, вместе со способом размещения данных, и является отдельно взятой файловой системой. В Linux посредством VFS (Virtual File System) различные файловые системы увязываются в единое дерево. Одна из файловых систем - начало начал, ее корневой каталог и есть root (/). А уже к ней примонтируются остальные файловые системы. VFS делает эту конструкцию прозрачной для прикладных программ.

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

Дальнейшее описание соответствует ext2fs - стандартной файловой системе ОС Linux, но классические файловые системы обычно устроены подобным образом. Единой и неделимой с точки зрения обращения к диску порции данных является логический блок, размер которого кратен степени двойки (обычно 1024 или 4096 байт). В логические блоки записываются собственно данные файлов. Но файлы могут быть разной длины, как маленькие, размером меньше логического блока, так и большие, занимающие несколько логических блоков. И файлов обычно много. Чтобы разобраться в мешанине данных (найти по имени нужный файл и нужную порцию данных в нем), а также снабдить файлы атрибутами-метаданными, часть логических блоков играет роль каталогов - списков пар (имя файла, индекс записи метаданных i-node) . В начале раздела располагается корневой каталог, который содержит ссылки на файлы и другие каталоги (содержащие ссылки на файлы и другие каталоги). Так образуется древовидная структура файловой системы.

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

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

Добавим в начале раздела загрузочный сектор, блок параметров раздела - и вот перед нами устройство файловой системы.

Все ссылки - это целые числа ограниченной разрядности, и от выбора их разрядности зависят ограничения на максимальный размер файловой системы и максимальный размер файла. Для 32-разрядной архитектуры максимальный размер файла ext2fs - 2 Гбайт, а при размере блока в 1 Кбайт максимальный размер файловой системы - 4 Тбайт. И эти цифры сегодня уже не кажутся огромными.

Не все коту масленица

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

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

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

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

В-четвертых, при модификации файла помимо записи самих данных нужно внести изменения в записи файловой системы (изменить метаданные, внести изменения в список блоков, пометить занятые блоки). И тут кроется самое страшное. Поскольку эти обращения к диску разнесены во времени (и это еще усугубляется кэшированием), в том случае, если в момент записи на диск произойдет веерное отключение или просто сбой питания, то мало того, что теряются данные, - может разрушиться вся файловая система. Кто работал в DOS с включенным кэшированием, тот наверняка оказывался у разбитого корыта разрушенной FAT. Еxt2fs в этом отношении немногим лучше, разве что поустойчивее (если честно, пока с крахом ext2fs я не сталкивался). В ext2fs при нормальном завершении работы системы раздел помечается как размонтированный. Если произошел сбой питания либо по привычке систему остановили выключением питания, то такой пометки не будет, и при следующей загрузке системы в работу вступит программа fsck (filesystem consistency check, аналог ScanDisk), которая сканирует файловую систему на предмет целостности. Если обнаруживаются несуразности, то «висячие» блоки оказываются в каталоге lost+found. Сам процесс этот довольно долгий, на больших дисках с большим числом файлов процесс проверки может длиться десятки минут, и даже часы. Все это время, естественно, система неработоспособна - прощай, высокая готовность. Конечно, если ведется регулярное резервное копирование, то данные можно восстановить, но время, время!

Хотя ext2fs достаточно устойчива, неудовлетворенность ею среди пользователей и администраторов вызревала. Объемы дисков растут, повышаются требования к надежности, ужесточаются требования к скорости восстановления работоспособности после сбоев. Ответом потребностям времени стали журналирующие файловые системы. В «больших» *nix они появились достаточно давно, в качестве примеров можно назвать XFS (для ОС IRIX от SGI) и JFS (для ОС AIX от IBM). В сообществе Linux также прикладываются усилия в этом направлении: например, ext3fs - «модернизация» ex2fs. Делаются и порты XFS и JFS (бета-версии уже доступны). Но одна разработка по стабильности и обкатанности опередила всех - это ReiserFS, удостоенная чести быть включенной в состав ядра Linux 2.4.1 (ранее она была доступна в виде патчей к ядру и поставлялась с некоторыми дистрибутивами на основе ядра 2.2).

Деревья B+ и журналирование

В ReiserFS основное внимание уделено решению проблемы эффективного хранения множества маленьких файлов. На помощь пришли технологии баз данных, решающих в общем-то те же проблемы хранения и доступа к данным. Это сбалансированные деревья B+Tree.

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

Другая особенность ReiserFS: в сбалансированных деревьях хранится все - имена файлов, каталоги, узлы i-node, маленькие файлы и хвосты больших файлов. Тела же больших файлов хранятся в неформатированных блоках. В целом оказывается, что для доступа к данным требуется меньше обращений и данные хранятся более плотно. Использование ReiserFS для хранения больших файлов не дает преимуществ перед ext2fs (но и не сильно проигрывает).

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

Интересной возможностью ReiserFS является поддержка модулей plug-in, которые позволяют создавать собственные типы каталогов и файлов. Это обеспечит развитие системы в будущем. Как пример: данные в системах потокового аудио/видео можно хранить в формате пакетов TCP/IP, избавляясь таким образом от накладных расходов на преобразование при передаче.

Цена использования журналирующей системы - дополнительные накладные расходы и более сложная реализация. А впадение в крайности может оказаться не оправданным. Ведь есть ряд разделов, содержимое которых после установки почти не меняется - bin, usr, - а вот часто меняющиеся - home, var - очень хорошие кандидаты для размещения на журналирующей файловой системе. Прелесть Linux - в прозрачном комбинировании различных файловых систем, что дает возможность использовать сильные стороны каждой из них в конкретных обстоятельствах. В целом, ReiserFS решает большинство проблем, присутствующих в ext2fs и, безусловно, укрепляет позиции Linux как платформы для серьезных приложений.

[i38356]