RAAAR.RU
Доброго времени суток, дорогой гость !
Если интересно, то можете почитать что-нибудь из этого:
___author: Пешеходов Андрей (filesystems@nm.ru) released: 18.05.2010 modified: 18.05.2010 Статья была опубликована в журнале "Системный администратор", No 12 (январьфевраль) 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 файлов, производительность поиска имени возросла в 50100 раз относительно 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.
|
|
|
|