Руководство по продвинутым файловым системам
Презентация ReiserFS

Дэниел Роббинс (Daniel Robbins), перевод Владимира Холманова, под редакцией Алексея Федорчука

Первоисточник: http://www-106.ibm.com/developerworks/library/l-fs.html
Июль 2001

Зачем оно нужно?

Что следует ожидать от прочтения этого цикла статей.

Цель этого цикла состоит в том, чтобы дать твердое, практическое введение в новые файловые системы для Linux, такие как ReiserFS, XFS, JFS, GFS, ext3 и другие. Я хочу "вооружить" читателя практичным взглядом на эти вещи и подготовить к осознанному использованию новых файловых систем. Цель так же в том, чтобы помочь Вам (насколько это возможно) избежать многих потенциальных ловушек. Иначе, предлагается осторожный просмотр файловых систем с позиций стабильности, производительности (плюсов и минусов), любых отрицательных воздействий на приложения, анализ комбинаций kernel/patch и т.п. Рассматривайте цикл статей как "insider's guide" для файловых систем нового поколения.

Это то, что следует иметь в виду. Однако, открывая цикл, я несколько отвлекаюсь от поставленной "практической" цели и отвлекаюсь на небольшое "теоретическое" вступление. Далее будут охвачены две темы, очень важные для Linux-сообщества - "журналирование" и "техническая" точка зрения на проект ReiserFS. Журналирование (Journalling) - технология, которую долго ждали, и пришло время ее практического использования. На этой технологии работают ReiserFS, XFS, JFS, ext3 и GFS. Важно точно понять, что собственно делает журналирование, и почему Linux в ней нуждается. Даже если вам это хорошо известно, я надеюсь, что мое введение в журналирование Вам будет полезно. Это хорошая "рыба" для объяснения технологии другим и кое-что для практики. Часто процесс внедрения нового приходится начинать с "Linux guy/gal", убеждая других в необходимости "качественного скачка".

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

Введение в журналирование: метаданные

Начнем с банального. Файловые системы существуют для того, чтобы хранить, находить и манипулировать данными. Для выполнения таких задач сама файловая система должна иметь внутреннюю "управляющую" структуру, которая позволяет все это делать. Такая внутренняя структура ("the data about the data") называется метаданными (meta-data). От организации метаданных зависят рабочие характеристики файловых систем (и это то, чем файловые системы друг от друга отличаются).

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

Введение в журналирование: утилита fsck

Поговорим о fsck. Где-то в начале загрузки Linux запускается fsck и начинается сканирование всех локальных файловых систем (перечислены в /etc/fstab). Делается это для того, чтобы гарантировать непротиворечивостьметаданных и, в конечном счете, возможность монтирования файловой системы. Такое сканирование занимает много времени и, в целях "экономии", предполагается следующее. Если Linux завершает работу корректно, то сброс на диск всех кэшированных данных происходит "штатно". В таком случае есть гарантия, что файловая система размонтирована "чисто" и готова к очередному монтированию. Как правило, fsck ограничивается только проверкой "флага чистого размонтирования" (clean byte) и, если проблем нет, делает разумное предположение, что с метаданными все в порядке.

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

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

Проблемы с fsck

Нельзя сказать, что описанное - плохой подход к обеспечению целостности файловой системы, но решение не оптимально. Не оптимальность результат того, что fsck должен просканировать все метаданные файловой системы для вывода об их непротиворечивости. Выполнение полной проверки всех метаданных задача сама по себе трудоемкая. К этому следует добавить, что с увеличением размера файловой системы затраты на полное сканирование растут прогрессивно (на персональной машине это может занять несколько минут, на сервере полчаса и больше). И еще, стандартное поведение fsck предполагает периодически проверки после некоторого числа "чистых размонтирований", что не может считаться приемлемым для mission-critical datacenter, когда "время - деньги". К счастью, имеется лучшее решение.

Журнал

Журналируемые файловые системы снимают проблему fsck через дополнительную стуктуру данных (data structure), называемую журналом. Такой журнал - on-disk structure. Прежде, чем драйвер файловой системы сделает любое изменение в метаданных, делается запись в журнал с описанием предстоящих действий. Только после этого происходит изменение самих метаданных. Таким образом, журналируемая файловая система обслуживает регистрационный файл последних модификаций метаданных. Затраты на ведение такого журнала несравненно ниже, чем сканирование всей файловой системы на предмет непротиворечивости метаданных.

Представьте себе цепочку - хранящиеся данные (stuff), "данные об этих данных" (the data about the stuff) - собственно метаданные, и журнал с метаданными о метаданных (the data about the data about the stuff).

Журналирование в действии

А что же делает fsck на журналируемой файловой системе? Обычно - ничего. Он просто "не видит" файловую систему и разрешает ее монтирование. Реальное волшебство быстрого восстановления файловой системы в непротиворечивое состояние ложится на драйвер файловой системы. Когда файловая система монтируется, он, сиречь драйвер, выясняет, все ли было в порядке. Если "чистого размонтирования" не было и метаданные должны быть исправлены то, вместо выполнения полного сканирования (как это делает fsck), драйвер читает журнал. Так как в журнале содержится хронология всех последних изменений метаданных, выполняется просмотр мизерной части meta-data. Вопрос о приведении файловой системы в непротиворечивое состояние решается в течение долей, максимум нескольких секунд. В отличие от традиционного (на сегодняшний день) подхода, время восстановления не зависит от размера файловой системы (зависит от интенсивности операций ввода/вывода (IO) в момент, предшествующий краху). Благодаря журналу снимаются многие проблемы, ставшие препятствием на пути увеличения размеров файловых систем.

ReiserFS

Теперь перейдем к ReiserFS, первой из нескольких журналируемых файловых систем, которые планируется исследовать. ReiserFS 3.6.x (версия для Linux 2.4) разработана Hans Reiser и его командой Namesys. Hans и его команда проповедуют философию, что лучшая файловая система та, которая формирует единую общедоступную среду, или namespace. В такой среде приложения могут взаимодействовать более гибко, эффективно и мощно. Для достижения этого, файловая система должна выполнять часть работы, традиционно выполнявшуюся приложениями. При таком подходе пользователи часто могут продолжать прямое использование файловой системы вместо формирования уровней специального назначения, типа баз данных и т.п.

Работа с маленькими файлами

Как обстоят дела с размещением в файловой системе большого числа маленьких порций информации? В Namesys решили, по крайней мере, для начала, сосредоточится на одном из аспектов работы файловой системы - работе с маленькими файлами. Строго говоря, файловые системы наподобие ext2 и ufs в этой области ведут себя неэффективно, часто вынуждая разработчиков проектировать базы данных или использовать другие "фокусы" для получения удовлетворительной производительности. Такой подход приводит к "изобретению множества велосипедов" и порождает огромное число несовместимых API узкоспециального назначения.

Разберемся, а за счет чего ext2 поощряет этот вид "велосипедного" программирования. Ext2 хороша для хранения достаточно большого числа файлов размером более двадцати килобайт каждый, но совсем не идеальна для хранения 2,000 50-байтовых файлов. Мало того, что заметно снижается производительность, но и само хранение маленьких файлов на ext2 приводит к неэффективному использованию дискового пространства, так как ext2 ассигнует под каждый файл целое число 1-2-4 KB блоков (размер блока устанавливается при формировании файловой системы).

Обычная житейская мудрость подсказывает нам отказаться от хранения многих смехотворно маленьких файлов непосредственно на файловой системе. Вместо этого возникает идея хранения информации в некоторой базе данных, работающей над файловой системой. В ответ на это Ханс Райзер (Hans Reiser) сказал бы, что всякий раз, когда формируется уровень над файловой системой, это свидетельствует лишь о том, что файловая система не отвечает нашим потребностям. Если бы она удовлетворяла, от этого можно было бы отказаться. Следовательно, хорошо спроектированная файловая система экономит время на разработку и устраняет ни с чем более не совместимый код.

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

Технология ReiserFS

За счет чего ReiserFS эффективно работает с маленькими файлами? ReiserFS использует специально оптимизированные сбалансированные деревья (b* balanced tree - одно на файловую систему) для организации всех данных файловой системы. Одно это дает большое увеличение производительности, а также снимает ряд искусственных ограничений на размещение файловой системы. Например, становится возможным иметь каталог, содержащий 100,000 других подкаталогов. Еще одна выгода от использования b*tree в том, что ReiserFS, подобно большинству других filesystems нового поколения, динамически ассигнует информационные узлы (inodes) вместо их статического набора, образующегося при создании "традиционной" файловой системы. Это дает большую гибкость и оптимальность в формировании пространства хранения.

ReiserFS также имеет ряд особенностей, нацеленных специально для улучшения работы с маленькими файлами. ReiserFS не связана ограничением в ассигновании памяти для файла в целом числе 1-2-4 KB блоков. По необходимости для файла может ассигноваться точный размер. ReiserFS также включает некоторые виды специальной оптимизации файловых "хвостов" для хранения конечных частей файлов, меньших, чем логический блок файловой системы. Для увеличения скорости, ReiserFS способен хранить содержимое файлов непосредственно внутри дерева b*tree, а не в виде указателя на дисковый блок (в ext2 есть понятие fastlink, когда содержимое "мягкой" ссылки до 60 байт хранится в inode).

Тем самым достигается две вещи. Первое, сильно увеличивается производительность, так как данные и метаданные (stat_data, иначе говоря, inode) информация может хранится рядом и считываться одной дисковой операцией ввода/вывода. Второе, ReiserFS способен упаковать хвосты (tail) файлов, экономя дисковое пространство. Фактически, при разрешении ReiserFS выполнять упаковку хвостов (значение по умолчанию) будет экономиться примерно шесть процентов дискового пространства (в сравнении с ext2).

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

ReiserFS - превосходная файловая система. В следующей статье будет описан процесс инсталляции ReiserFS под Linux 2.4. Будет описана процедура оптимальной настройки под требования приложений, опции ядра и другое.