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

released: 18.05.2010

modified: 18.05.2010

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

года.

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

(продолжение) начало там

Отложенное и многоблочное размещение.

Аллокатор ext3 может размещать только по одному блоку за раз, что не

эффективно при высокой интенсивности ввода­вывода. Т.к. запросы на выделение

блоков передаются на уровень VFS по одному за раз, аллокатор ext3 не может

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

сказывается на фрагментации ФС.

Отложенное размещение – хорошо известная техника, суть которой

заключается в отсрочке выделения блоков до времени сброса страниц (flush). Это

позволяет обеспечить более эффективную, сточки зрения фрагментации и

нагрузки на CPU, группировку запросов на размещение. Короткоживущие

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

оставаясь лишь в кэше. Патчи с реализацией отложенного размещения для ext4

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

уровень VFS для его разделения с другими файловыми системами.

С появлением отложенного размещения стало возможно реализовать т.н.

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

целыми экстентами, что исключает множество лишних вызовов ext4_get_blocks() и

ext4_new_blocks() и уменьшает нагрузку на процессор.

Многоблочное размещение в ext4 реализовано через сбор информации о

свободных экстентах в каждой группе блоков при монтировании ФС и организации

ее хэширования в оперативной памяти.

Прирост производительности от отложенного и многоблочного размещения

оказался очень существенным – на 30% возросла пропускная способность ФС,

нагрузка на CPU снизилась почти на 50%. Цена этого решения – увеличение

времени монтирования ФС.

Кроме прочего, в разработке находятся еще две возможности,

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

связывают большие надежды по серьезному уменьшению фрагментации ФС:

Перспективное предразмещение (in­core preallocation) – информацию о

•

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

механизма предразмещения и резервирования дискового пространства.

Каждый inode может иметь несколько заранее зарезервированных

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

HPC­приложениям запись в файл со множества узлов по совершенно не

предсказуемым смещениям.

Группы размещения (locality groups) – в настоящее время решение по

•

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

если аллокатор будет располагать информацией о логических

взаимосвязях объектов ФС, он сможет размещать связанные файлы

ближе друг к другу, что существенно улучшит производительность

чтения/поиска. Аллокатор может отслеживать некоторое количество еще

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

для них соответствующее количество дискового пространства. Этот

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

назначения конкретных блоков конкретным файлам. Все это, ценой

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

уменьшению фрагментации файловой системы и более оптимальному, с

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

диске.

Можно с уверенностью сказать, что ext4 располагает достаточно мощным

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

современным требованиям к эффективной обработке больших и маленьких

дисковых запросов под многопоточными нагрузками.

Фоновая дефрагментация.

Хотя функционал, описанный выше, существенно улучшает

фрагментационную устойчивость файловой системы, со временем, на активно

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

Для решений этой проблемы была разработана программа e4defrag, способная

дефрагментировать как отдельные файлы, так и весь том. При работе на

отдельным файлом программа создает временный inode и выделяет под все данные

файла один (если возможно) или несколько экстентов, используя многоблочное

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

inodes подменяются на новые, и временный inode удаляется.

Надежность .

Надежность хранения данных является одной из самых важных

характеристик ext3, и, пожалуй, главной причиной ее популярности. Стараясь

сохранить эту репутацию, разработчики ext4 приложили много усилий для

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

журналирования и различных RAID­конфигураций, многие файловые системы

подвержены различным разрушениям дисковой структуры. Поэтому первой линией

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

комбинирующее устойчивый формат хранения, избыточность на разных уровнях и

проверка целостности с помощью контрольных сумм.

Одна из важнейших характеристик любой файловой системы – время

восстановления после сбоя. К примеру, на вполне обычном в наше время массиве

объемом в 2 Tb ext3 будет восстанавливаться до работоспособного состояния, в

среднем, от двух до четырех часов, а в худшем случае – до нескольких суток.

Использование экстентов очень хорошо сказалось на масштабировании этого

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

Подсчет неиспользуемых inodes и ускорение e2fsck .

Безусловно, наиболее трудоемкой операцией в e2fsck является проверка

inodes на первом проходе. Она требует чтения с диска всех таблиц inodes, поиск в

них целых, разрушенных и неиспользуемых inodes, внесение необходимых

исправлений и обновление битовых карт размещения блоков и inodes.

Неиспользуемые группы блоков и таблицы inodes теперь имеют особую логическую

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

позволит существенно уменьшить общее время работы e2fsck. Эта возможность

может задействована во время mke2fs или позднее, с помощью опции ­O

uninit_groups утилиты tune2fs.

С этой опцией ядро сохраняет количество неиспользуемых inodes в конце

inode­таблицы каждой группы блоков. В результате e2fsck может пропустить как

чтение этих блоков с диска, так их сканирование на предмет поиска разрушений.

Для подтверждения подлинности информации о неиспользуемых inodes

дескриптор группы содержит контрольную сумму (CRC16).

Т.к. типичная ФС типа ext3 использует от 1 до 10 процентов своих inodes и

все они находятся в началах inode­таблиц, указанное нововведение позволяет

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

проходе e2fsck. В настоящее время драйвер ext4 не увеличивает счетчик

неиспользованных inodes при удалении файлов – это делает только e2fsck.

Поэтому на ФС с большим количеством удаленных файлов fsck будет работать

значительно быстрее при втором запуске.

Контрольные суммы.

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

позволяет ext4 быстрее и достовернее отыскивать разрушения и соответственно на

них реагировать, вместо того, что бы слепо верить прочитанным с диска данным.

Дескриптор группы блоков в ext4 также защищен контрольной суммой, в планах на

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

метаданных в нем очень высока, что существенно повышает риск разрушения ФС в

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

Соответствующий патч в настоящее время почти готов к внесению в код ext4.

Каждая транзакция имеет блок­заголовок и фиксирующий блок (commit­

block). Во время нормальной журнальной операции фиксирующий блок не

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

Следующая транзакция будет вынуждена ждать полной фиксации предыдущей,

прежде чем начинать изменение ФС. Таким образом, совпадение номера

транзакции у заголовка и фиксирующего блока служит сигналом к запуску этой

транзакции во время восстановления ФС, а если номера различаются – чтение

журнала прекращается. Однако существуют несколько сценариев, в которых

подобное поведение может вызвать разрушение метаданных.

В защищенном журнале драйвер ext4 вычисляет контрольную сумму (CRC32)

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

блок. Если, при восстановлении из журнала, обнаруживается несоответствие этой

контрольной суммы фактически прочитанным с диска данным, это значит, что один

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

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

отбрасывается целиком, а пользователю рекомендуется воспользоваться e2fsck.

Также значительным выигрышем от использования подобной защиты

журнала является отказ от пошаговой фиксации транзакции (запись

фиксирующего блока теряет всякий смысл), что может увеличить пропускную

способность журнала более чем на 20%.

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

контрольными суммами для экстентов, битовых карт, inodes и, возможно, даже

каталогов. С появлением контрольных сумм в журнале все это выполняется

введением лишь небольшого количества дополнительной логики – ведь все эти

структуры при модификации обязательно проходят через журнал (нельзя не

заметить, что от ошибок диска на местах постоянного пребывания этих данных

такая схема никоим образом не защищает).

Другие нововведения.

Разработчики продолжают постоянно добавлять новые возможности в ext4.

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

наносекундных временных штампов и отслеживание версий inode (versioning). Эти

две возможности позволяют достичь абсолютной точности при работе с временем

доступа к файлу и отслеживании изменений в нем.

Ext3 располагает тайм­штампами второго порядка, однако на современных

высокопроизводительных процессорах и системах хранения этого недостаточно.

С введением увеличенного inode в ext4 появилась возможность записывать

временные штампы с наносекундной точностью, на что достаточно 30 бит 32­

битного поля штампа. Оставшиеся 2 бита применяются для расширения эпохи на

272 года.

Клиенты 4­й версии NFS нуждаются в возможности обнаруживать изменения

в файле, сделанные на стороне сервера, что бы поддерживать клиентский кэш в

актуальном состоянии. Для этого в ext4 на каждый inode введен глобальный 64­

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

Сравнивая значения счетчика на стороне сервера со своим, клиент NFSv4 может

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

переполнение не имеет значения, т.к. проверяется лишь равенство.

Миграция на ext4

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

совместимости ext3 с ext2, и пользователи очень оценили эту возможность. Однако,

в случае с ext4, ряда несовместимых с ext3 изменений дискового формата избежать

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

новой версии, также, как это было при переходе с ext2. Доступны методы как для

простого ознакомления с возможностями новой ФС, так и для миграции всей

файловой системы без применения резервных копий.

Существует очень простой способ обновления ext3 для использования

экстентов и других возможностей ext4 без каких либо изменений на диске.

Достаточно просто смонтировать существующую ext3 как ext4, и вновь созданные

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

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

позволяет драйверу различать формат inode и поддерживать их сосуществование в

одной файловой системе. Все новые возможности ext4, основанные на применении

экстентов (предразмещение, многоблочное размещение), буду немедленно

доступны для вновь созданных файлов.

Кроме того, для полной миграции с ext3 на ext4 со временем будет

подготовлена специальная утилита, осуществляющая преобразование косвенной

структуры адресации в экстентную, и увеличивающая размер inode до 256 байт. В

качестве частичной меры переход к экстент­адресации может быть выполнен

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

которой файлы не только перемещаются в новые экстенты, но и

дефрагментируются. Эта процедура может работать на смонтированной ФС.

Полный переход к ext4 , включая преобразование inodes, осуществляется

только на отмонтированной ФС, путем сканирования всей файловой системы,

переформатирования inodes и перехода к экстент­адресации.

Откат с ext4 обратно к ext3 также возможен, хотя и не столь очевиден и

красив, как обновление ФС. Для этого необходимо смонтировать раздел с опцией

­noextents, скопировать все файлы во временные, а затем заменить ими

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

адресации, необходимо, с помощью tune2fs, сбросить флаг INCOMPACT_EXTENTS,

а затем смонтировать ФС как ext3.

Для выполнения полной миграции на ext4 с файловых систем предыдущих

поколений (ext2/3) разработчики, не смотря на признанную стабильность кода

новой ФС, рекомендуют сделать резервную копию важных данных с обновляемого

раздела. Т.к. обновленный раздел более не удастся примонтировать как ext2/3,

необходимо убедиться, что вы располагаете необходимым набором ПО для

полноценного использования новой файловой системы:

e2fsprogs 1.41.6

•

mount 2.16

•

ядро Linux от 2.6.28 и выше

•

grub 1.96+20090808 (если обновляется загрузочный раздел)

•

Если обновляется раздел ext2, то для начала нужно конвертировать его в

ext3:

sudo tune2fs -j [device]

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

файловой системы на наличие ошибок:

fsck.ext3 -pfy [device]

Затем включаем все предоставляемые ext4 новые возможности:

tune2fs -O extents,uninit_bg,dir_index [device]

После чего также рекомендуется пройтись по разделу утилитой fsck:

fsck.ext4 -yfpD /dev/sdc1

Опция ­D заставит fsck заняться оптимизацией каталогов – для директорий с

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

каталогов ext3 – пересортировка и сжатие. Опция ­p отвечает за проверку ошибок,

­y заставит утилиту автоматически отвечать согласием на все возникающие в ходе

проверки вопросы, ­f – принудительная проверка даже в случае, когда файловая

система выглядит чистой.

ext4 на фоне предшественников и конкурентов

Посмотрим на сравнительную таблицу основных характеристик ext3, ext4 и

XFS (как наиболее производительной и функциональной, по мнению автора, из

современных ФС):

Мнение автора

Как видно из приведенной выше таблицы, ext4 уступает по многим

параметрам даже разработанной более 15 лет назад XFS, не говоря уже о

файловых системах нового поколения – ZFS и btrfs. И все же она остается

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

как наиболее надежную и хорошо поддерживаемую файловую систему с богатым

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

Довольно легко обновив существующие ext2/3 разделы до новой версии,

пользователи получают для своих хранилищ достаточно производительную и очень

надежную ФС, не имеющую каких­либо явных ограничений, типа максимального

размера раздела или файла.

Источники

1. Исходные тексты ядра Linux версии 2.6.32

2. http://ext4.wiki.kernel.org

3. Ext4 block and inode allocator improvements

(http://ols.fedoraproject.org/OLS/Reprints­2008/kumar­reprint.pdf)

4. The new ext4 filesystem: current status and future

plans(https://ols2006.108.redhat.com/2007/Reprints/mathur­Reprint.pdf)

Вернуться

На главную