RAAAR.RU

Доброго времени суток, дорогой гость !

Если интересно, то можете почитать что-нибудь из этого:

На главную страницу сайта Оборудование для предприятий железных дорог Фото и видео Отчёты и очерки о путешествиях Туристическое снаряжение Философия всех времён и народов Литература художественная и нехудожественная UNIX и около него Разное в ассоритменте Кто мы и где мы Вход для однажды входивших и регистрация новых пользователей




___author: Пешеходов Андрей (filesystems@nm.ru)

released: 18.05.2010

modified: 18.05.2010

Статья была опубликована в журнале "Системный администратор", No 1­2 (январь­февраль) 2010

года.

Не новое, но хорошо доработанное старое: взгляд на ext4



Ext3 много лет является наиболее популярной файловой системой для Linux.

Для соответствия возможностям новых жестких дисков и требованиям времени на

ее основе была разработана ФС нового поколения – ext4, сочетающая в себе

улучшенные масштабируемость и производительность при поддержке больших

файловых систем с сохранением надежности и стабильности ext3. Ext4 подходит

для самых разнообразных рабочих нагрузок и способна полностью заменить ext3 в

качестве "файловой системы Linux".

Здесь мы рассмотрим мотивы разработки ext4, ее новые возможности,

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

Введение

Ext3 стала столь популярной файловой системой благодаря своей

надежности, богатому набору возможностей, относительно хорошей

производительности и отличной совместимости с предыдущими версиями Extended

File System. Консервативный дизайн ext3 создал ей репутацию высоконадежной, но

несколько ограниченной – в работе с большими хранилищами – файловой системы.

Одно из наиболее неприятных ограничений ext3 – максимальный размер

файловой системы в 16 Tb. Многие корпоративные решения, в наше время,

столкнулись с этим лимитом, более того, многотерабайтные массивы становятся все

более доступны и домашним пользователям.

Для снятия этого ограничения в августе 2006­го была опубликована серия

патчей, дающих ext3 две ключевые возможности: поддержку больших разделов и

учет блоков на экстентах (необходимый из­за того, что обработка битовых карт

даже на терабайтном разделе довольно сильно нагружает CPU и память). Эти

патчи необратимо меняли дисковый формат и нарушали обратную совместимость.

Из соображений поддержания стабильности кода ext3 разработчики решили

создавать на основе этих патчей новую файловую систему, назвав ее ext4.

Основная цель новой ФС – решить проблемы производительности,

надежности и масштабируемости, характерные для ext3. На вопрос об

использовании XFS или разработки новой ФС с нуля есть простой ответ –

необходимо было обеспечить огромному количеству пользователей ext3

возможность легко обновить их файловые системы – как это было сделано при

переходе с ext2. Также разработчикам не хотелось пренебрегать значительными

усилиями, вложенными в надежность и функциональность ext3 и e2fsck, а

сосредоточится на достаточно быстром добавлении новых возможностей.

Так была рождена ext4, присутствующая в основной ветке начиная с ядра

2.6.19 и помеченная стабильной с 2.6.28 (после двух лет разработки).

Масштабирование

16­терабайтный лимит размера раздела в ext3 обусловлен 32­битным

номером блока. Логичным решением проблемы является использование большего

количества битов под этот параметр по всему коду ФС.

В экстент­патче для ext3 вводились 48­битные номера блоков, сохраненные и

в ext4. Теперь поддерживаются разделы размером до 1 Eb при 4­килобайтном

блоке.

После расширения номера блока до 48 бит потребовалось внести изменения

в метаданные ext4 – суперблок, дескриптор группы блоков и журнал. Новые поля

были добавлены в конец суперблока, расширяя s_free_blocks_count (количество

свободных блоков), s_blocks_count () и s_r_blocks_count до 64 бит. Аналогичным

образом был скорректирован и дескриптор группы блоков – были расширены

указатели на битовую карту и таблицу inodes.

Уровень журналирования блоков, JBD, был переработан в JBD2 для

поддержки новых возможностей ext4. Хотя в настоящий момент подсистему JBD2

использует только ext4, потенциально она может обеспечить журналирование для

любой 32­х или 64­битной файловой системы.

48­битная разрядность номера блоков была выбрана потому, что, во­первых,

предела размера ФС в 1 Eb должно хватить на много лет вперед, и, во­вторых,

полная проверка с помощью e2fsck экзабайтного раздела займет 119 лет при

современных скоростях дисков.

Несмотря на расширение номера блока до 48 бит, размер раздела ext4 все

еще ограничен количеством групп блоков в файловой системе. В ext3, из

соображений безопасности, все дескрипторы групп блоков продублированы в

первой из них. Т.к. новый дескриптор группы блоков имеет длину 64 байта, ext4

могла бы иметь объем не более 256 Tb.

Решение проблемы – использовать метагруппы блоков (META_BG),

существующие в ext3 начиная с ядра 2.6.0. С опцией META_BG ext4 разбивается на

несколько метагрупп, каждая из которых является кластером такого количества

групп блоков, дескрипторы которых могут храниться в одном блоке ФС. В 4­

килобайтном блоке помещается 64 дескриптора нового формата, т.е. одна

метагруппа может адресовать до 8 Gb дискового пространства. Ипользование

метагрупп позволяет вынести дескрипторы конкретных групп блоков из

перегруженной первой группы раздела в первые группы каждой метагруппы.

Резервные копии дескрипторов хранятся во второй и последней группе блоков

каждой метагруппы. Все эти меры позволяют адресовать с помощью групп блоков 1

Eb дискового пространства.

Экстенты

Файловая система ext3 отслеживает блоки данных файлов и каталогов с

помощью косвенно­блочной схемы. Этот подход достаточно эффективен для

сильно фрагментированных или маленьких файлов, но очень накладен для

больших хорошо упакованных файлов – особенно на операциях удаления/усечения.





Экстентом называется дескриптор, определяющий участок в несколько

непрерывно расположенных дисковых блоков. В ext4 экстент может адресовать до

128 Mb дискового пространства при 4­килобайтном блоке. 4 экстента могут

храниться прямо в inode – их вполне достаточно для небольших или

нефрагментированных файлов. Когда встроенных экстентов не хватает, для

адресации блоков файла используется дерево экстентов постоянной глубины (см.

Рис. 1). Корень этого дерева хранится в inode, сами экстенты – в листьях. Каждый

узел дерева начинается с заголовка (fs/ext4/ext4_extents.h):







В будущем, специально для эффективного хранения фрагментированных

файлов, возможно введение нового типа экстентов (с отличным magic­

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

надежности определения разрушений, не исключено дополнение узлов дерева

экстентов, помимо заголовка, еще и "хвостом", в котором будут содержаться номер

inode, номер поколения и контрольная сумма.

Большие файлы

В файловой системе ext3 размер файла ограничен 32­битным полем i_blocks

в inode, содержащем количество секторов (512 байт), занимаемых файлом. В итоге,

максимальный размер файла в ext3 ограничен величиной 2^32 * 512 = 2Tb, что для

ФС нового поколения недостаточно.

В ext4 эта проблема решена достаточно прямолинейно и бесхитростно:

разрядность поля i_blocks увеличена до 48 бит, размер теперь исчисляется в

блоках. В итоге размер файла ext4 ограничен только 32­битным номером

логического блока в текущем формате экстента и составляет 16 Tb. В будущем

планируется снятие и этого ограничения и достижение полной 48­битной емкости в

несколько Eb.

Большие каталоги

Некоторые приложения уже в наше время оперируют миллиардами файлов, и

даже замахиваются на триллионы. Теоретически ext4, располагая 32­битным

номером inode, может оперировать миллиардами файлов, однако на практике эта

величина не достижима из­за архаичного статического выделения inodes,

пришедшего в Extended Filesystem еще из BSD FFS. Т.е. количество файлов на

разделе жестко задается во время создания ФС. Задумавшись о реализации

динамического выделения inodes с увеличенными 64­битными номерами,

разработчики остановились на следующих моментах:

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

номеров inodes в их физическое положение на диске

устойчивость к ошибкам оборудования: e2fsck должна иметь

возможность быстро отыскивать все inodes после разрушения ФС

совместимость: необходимо решать проблемы обработки 64­битных

номеров inodes на 32­битных машинах

При динамическом выделении inodes они больше не обладают

фиксированным положением на диске. Одним из способов отображение номера

inode на номер содержащего его блока является прямое кодирование координат

inode в его номере, как это сделано в XFS. Недостатки этого метода проявляются

при усечении или дефрагментации файловой системы – то есть в тех случаях,

когда inodes требуется перемещать. В этом случае сервисной программе придется

вникать и вносить изменения в структуру каталогов, что ведет к существенной

потере производительности и увеличивает риск разрушения ФС в случае сбоя

оборудования во время работы программы. Панацеей здесь может стать введение

дополнительных карт, отображающих старые координаты inodes на новые, что, тем

не менее, трудно назвать хорошей идеей. Решение же проблемы поиска

динамически выделяемых inodes с помощью идексирующих их бинарных деревьев

(как это сделано в подавляющем большинстве файловых систем) приведет к полной

переделке структуры ФС, утраты аккумулирущей роли групп блоков и, фактически,

выльется в создание полностью новой и ни с чем не совместимой ФС, что

неприемлемо. То же можно сказать и о расширении номера inode до 64 бит.

Выгоды от динамического выделения и 64­битных номеров inodes очевидны,

однако объем требуемых изменения дисковой структуры необычайно велик,

поэтому в настоящее время эти вопросы все еще находятся в стадии обсуждения.

Соответствующий функционал не вошел в релиз, и, видимо, будет реализован не

скоро (а, по мнению автора, не будет реализован вообще – в свете успехов в

разработке btrfs (btrfs.wiki.kernel.org) и все большего внимания к ней со стороны не

только пользователей, но и многих мэйнтейнеров ядра).

Масштабируемость каталогов

Объем каталога ext3 ограничен величиной в 32 000 файлов. В ext4 этот лимит

полностью устранен – то есть количество файлов в одном каталоге там не

ограничено. Для поддержки больших каталогов в ext4, вместо односвязного списка,

используется схема индексирования их элементов с помощью так называемых

HTree­структур – своего рода B­деревьев постоянной глубины, индексирующих

элементы директории по 32­битному хэшу имени. Для каталогов, содержащих более

10 000 файлов, производительность поиска имени возросла в 50­100 раз

относительно ext3.

Inodes и расширенные атрибуты

Ext3 поддерживает inodes различного размера, задаваемого во время mke2fs

параметром ­I [inodes_size]. В ext4 минимальный размер inode увеличен вдвое – до

256 байт. Для сохранения совместимости с кодом драйвера ext3 и e2fsck

размеченная часть inode имеет старый формат. В дополнительной секции

расположены несколько новых полей (к примеру, наносекундные временные

штампы) и динамическая область, используемая под расширенные атрибуты

(extended attributes, EAs).








Размер дополнительной секции может меняться от версии к версии и

хранится в поле i_extra_isize, следующем сразу за старой 128­битной частью.

Суперблок содержит 2 связанных с этим вопросом поля: s_min_extra_size

(гарантированный размер дополнительной статической области) и

s_want_extra_size (желаемый некоей версией, но не гарантируемый размер экстра­

области).

Оставшееся пространство в inode может быть использовано для хранения

встроенных расширенных атрибутов прямо в inode, что существенно увеличивает

производительность их обработки. Также по­прежнему доступен дополнительный

EA­блок, позволяющий хранить еще 4 Kb атрибут­данных для каждого файла.

Возможность хранения большего количества EAs в форме регулярного каталога не

реализована.

Предразмещение (preallocation)

Некоторым приложениям, например базам данных и потоковым медиа­

серверам, необходимо предразмещать "впрок" блоки для расширения файла, но без

записи в них каких­либо данных. Предразмещение позволяет выделять блоки как

можно более непрерывно и гарантирует необходимое пространство для записи в

пределах предразмещенной области. Внутренне файловая система рассматривает

неинициализированные участки фала как заполненные нулями, что позволяет

избежать несанкционированного просмотра устаревших данных. Предразмещение

должно быть устойчивым к перезагрузке, в отличие от так называемого

резервирования блоков в ext3/4.

В ext4 предразмещение реализовано вполне традиционно –

неинициализированный экстент имеет специальную пометку, обнаружив которую

при попытке чтения экстента, файловая система вернет приложению блок нулей.

При записи в середину такого экстента он разбивается на две части – одна

дополняется нулями и пишется на диск, другая остается "виртуальной".

В настоящее время все файловые системы Linux, располагающие

соответствующим функционалом, принимают запросы на предразмещение через

ioctl(). В будущем (по скольку таких ФС становится все больше) планируется

введение специального системного вызова, реализующего posix_fallocate API.



Читать далее

На главную





ЯРЮРХЯРХЙЮ

Рейтинг@Mail.ru