Насколько эффективен fast_commit для ext4 и почему он не включен по умолчанию

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

Научиться настраивать MikroTik с нуля или систематизировать уже имеющиеся знания можно на углубленном курсе по администрированию MikroTik. Автор курса, сертифицированный тренер MikroTik Дмитрий Скоромнов, лично проверяет лабораторные работы и контролирует прогресс каждого своего студента. В три раза больше информации, чем в вендорской программе MTCNA, более 20 часов практики и доступ навсегда.

Немного теории

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

Чтобы ответить на этот вопрос, вспомним как работают журналируемые файловые системы. Учитывая, что современные файловые системы достаточно сложны в своем устройстве, мы намеренно упростили подачу материала до уровня достаточного для понимания происходящих процессов.

Начнем с базового устройства. Файловая система представляет собой особым образом организованное дисковое пространство, разделенное на логические единицы хранения данных (кластеры, блоки и т.д.). Однако недостаточно просто поместить данные файла в блоки, тем более, что файл не обязательно будет занимать непрерывную последовательность блоков, он может быть раскидан по всему диску вперемешку с данными иных файлов. Кроме того, в файловой системе могут существовать и более высокоуровневые объекты, например, жесткие ссылки, и тогда содержимое блока может принадлежать сразу нескольким файлам. Также следует каким-то образом учитывать дополнительные атрибуты: владельца, права доступа и т.д. и т.п.

Чтобы решить этот вопрос файловые системы содержат не только пользовательские данные, но и метаданные, это специальный набор служебных данных, который используется для получения информации о фактическом расположении данных файла и его атрибутов. Таким образом, записав на диск новые данные или изменив существующие мы также должны внести изменения в метаданные, чтобы файловая система могла найти данные по месту их фактического расположения. Это чем-то напоминает библиотечный каталог, если мы перенесли книгу со стеллажа А на стеллаж Б, то мы должны отразить это изменение в каталоге, иначе книгу никто не найдет.

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

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

Давайте проведем другую аналогию, допустим у нас есть большой склад, складские работники берут накладные заказчиков и выдают им купленные товары. И вот в самый разгар работы погас свет. В темноте что-то уронили, что-то подняли, что-то не там взяли, не туда положили. Когда снова включат свет у нас будет на складе полный хаос с кучей разбросанного по полу товара. В итоге неизбежно кому-то чего-то не додадут, кому-то выдадут лишнее, а кто-то получит совсем не то, что заказывал. Ну и в ближайшую инвентаризацию будет весело.

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

Можно ли как-то избежать подобной ситуации? Можно. Если мы вернемся на наш склад, то добавим в накладные два поля: товар получил и товар выдал. Взяв с полки товар, кладовщик отмечает, что он его получил, а отдав заказчику ставит вторую пометку - выдал. И только после того, как будут установлены обе пометки, операция считается завершенной. Здесь мы вплотную подходим к понятию транзакции - операции или набора операций, которые могут быть либо полностью выполнены, либо полностью откачены, промежуточного состояния транзакции быть не может.

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

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

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

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

Но как быть, если данные важны, и мы должны убедиться в том, что они действительно записаны на диск? В POSIX-системах для этого существует специальный системный вызов fsync, который предписывает принудительно сбросить все данные файла из кеша и буферов на диск и зафиксировать транзакцию. Использование fsync значительно повышает надежность, но весьма негативно сказывается на производительности.

Вот здесь мы и подошли к fast_commit - это новый, оптимизированный механизм фиксации транзакций в файловой системе, он не заменяет, а дополняет существующие механизмы и в ряде случаев способен дать существенный прирост производительности операций записи. Т.е. мы более быстро фиксируем транзакции и позволяем повысить производительность в том случае, если она упирается в журнал. Никаких чудес от данной функции ожидать не стоит, ваш медленный ноутбучный диск на 5400 rpm от нее летать не начнет.

Что показывают тесты?

Согласно тестам fast_commit весьма и весьма эффективен, но мы не будем принимать все на веру и организуем собственное тестирование, для этого будем использовать диск Samsung 860 EVO 250 ГБ SSD M.2 и операционную систему Ubuntu 22.04 LTS с ядром 5.15.0-37. В качестве тестов мы будем использовать приложения Fsmark и Dbench из штатного репозитория ОС.

Benchmark	Config	fast_commit off	fast_commit on
Fsmark	Local, 8 threads	1562 Files/sec	7006 Files/sec
Dbench	Local, 2 procs	27.8 MB/sec	264.64 MB/sec
Dbench	Local, 10 procs	97.58 MB/sec	493.34 MB/sec

Результаты действительно отличные. Здесь даже не двукратный прирост, а увеличение производительности в разы, а то и на порядок. Скажем. в тесте Dbench Local, 10 procs мы просто уперлись в производительность диска. Но почему тогда в дистрибутивах fast_commit не включен и новые файловые системы создаются без этой опции?

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

И что мы видим? Да ничего, никакого эффекта от включения fast_commit для повседневных задач и нагрузок нет. Почему так? Как раз об этом мы много говорили выше, fast_commit эффективен в тех случаях, когда производительность записи упирается в журнал, повседневные задачи не испытывают необходимости в гарантированной записи на диск, их вполне устраивает кеширование и буферизация записи, поэтому вызывать fsync нет необходимости и fast_commit оказывается бесполезен.

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

От теории к практике

Но довольно теории, давайте перейдем к практике, каким образом можно включить fast_commit для файловой системы ext4? В первую очередь в момент ее создания, при форматировании раздела используйте команду:

mkfs.ext4 -O fast_commit /dev/sdb1

В нашем случае мы отформатировали раздел /dev/sdb1.

Проверить включен ли fast_commit можно командой:

tune2fs -l /dev/sdb1 | grep fast_commit

Пустой вывод означает, что функция не подключена, иначе вы должны увидеть что-то похожее:

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

Для отмонтирования используйте команду:

umount /dev/sdb1

Затем добавьте нужную опцию:

tune2fs -O fast_commit /dev/sdb1

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

mount -a

Если вы хотите включить fast_commit для корневой файловой системы, то вам потребуется загрузиться с Live-CD и внести изменения в суперблок с него.

Ну и еще один насущный вопрос: а как обстоят дела с совместимостью? Что будет если мы включим fast_commit, а потом подключим этот диск к системе с ядром ниже, чем 5.10? Ничего страшного, в файловых системах ext строго соблюдается принцип обратной совместимости, мы можем даже смонтировать ext4, как ext2 и прочитать оттуда все данные. Поэтому никаких проблем совместимости от включения fast_commit у вас не возникнет.

Записки IT специалиста