ext4 и Btrfs: скорость, место и восстановление данных

Между максимальным и минимальным результатом 2,5 MiB/s, или примерно 3,3 % от максимальной скорости. Для этого теста разница невелика, но переносить вывод на любой накопитель и любую задачу нельзя.

Скорость, расход места и восстановление данных зависят от разных механизмов. ext4 записывает изменения по традиционной схеме и использует журнал, прежде всего для согласованности файловой системы после сбоя. Btrfs применяет copy-on-write, поддерживает снимки, контрольные суммы и сжатие. Это меняет и поведение при записи, и то, какие варианты восстановления остаются после ошибки или случайного удаления.

Почему тесты скорости не дают универсального ответа

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

Поэтому результат одного теста не отвечает на вопрос, какая файловая система быстрее в целом. Он описывает конкретную комбинацию нагрузки, оборудования, ядра и настроек. В тесте Phoronix от 9 августа 2024 года использовались Linux 6.11-rc2, Ubuntu 24.04 LTS, SSD Solidigm D7-PS1010 PCIe 5.0 ёмкостью 7,6 TB и заново отформатированные файловые системы с настройками монтирования по умолчанию. Это полезная точка сравнения, но не универсальный рейтинг.

В опубликованных результатах картина зависела от теста:

• При последовательной записи Btrfs показала умеренно лучший результат, чем Bcachefs. ext4, XFS и F2FS оказались сопоставимы.
• В SQLite-тесте с четырьмя параллельными базами Btrfs с настройками по умолчанию уступала ext4 и XFS.
• В тесте случайного чтения блоков по 4 КиБ Btrfs также отставала от ext4 и XFS.

Даже внутри одного набора испытаний нельзя свести результаты к одной цифре «скорости файловой системы». Тем более эти тесты не равны копированию произвольного набора файлов. Для такого сравнения нужно зафиксировать структуру набора, источник и назначение данных, состояние кэша, параметры монтирования и способ измерения. Прямого воспроизводимого замера ext4 против Btrfs на одинаковом наборе файлов и одинаковых условиях в приведённой фактуре нет.

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

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

Расход места: CoW, снимки и сжатие в Btrfs

Btrfs использует copy-on-write, или CoW. При изменении данных файловая система записывает новое содержимое в другие блоки и обновляет ссылки на него. Старые блоки освобождаются, когда на них больше никто не ссылается. Это отличается от привычной схемы, при которой изменённое содержимое записывается на место прежнего.

У такого подхода есть важное следствие для снимков. Снимок Btrfs в момент создания не является полной копией подтома: он разделяет с ним уже существующие блоки. Пока содержимое не меняется, дополнительный расход места в основном связан с метаданными. Когда файл изменяют или удаляют, снимок может продолжить ссылаться на прежние блоки. Они останутся занятыми, пока существуют ссылки на них.

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

Рефлинк работает на похожем принципе совместного использования блоков, но применяется к копированию файлов. При создании reflink-копии файловая система может создать новые ссылки на существующие блоки вместо немедленного физического дублирования содержимого. После изменения одной из копий Btrfs записывает изменённые данные отдельно. Это экономит место и время там, где приложение умеет использовать reflink, но не означает, что две копии навсегда займут один и тот же объём.

Сжатие также влияет на расход места и скорость. Btrfs умеет сжимать данные на лету, в частности с помощью zstd, lzo и zlib. Выигрыш зависит от содержимого: хорошо сжимаемые данные занимают меньше блоков, уже сжатые файлы обычно дают куда меньшую экономию. В тесте заполнения конфигурация zstd:3 показала 73,2 MiB/s против 75,7 MiB/s без сжатия. Разница между этими результатами составляет примерно 2,5 MiB/s. Это конкретный тест, а не правило для любой нагрузки: скорость компрессии зависит и от процессора, и от характера данных.

У ext4 нет встроенных снимков, reflink и прозрачного сжатия в том же смысле, что у Btrfs. Его модель записи проще для понимания: место файла связано с размещёнными на диске блоками, а снимки и резервные копии организуют отдельными средствами. Но простота не отменяет необходимости следить за свободным пространством и не превращает ext4 в систему восстановления удалённых данных.

При активных снимках расход места Btrfs нужно оценивать не только по размеру текущих файлов. Старые версии данных могут удерживаться снимками и другими ссылками. Если часто перезаписывать большие объёмы, сохранённые состояния способны занять значительное пространство. Это не скрытая копия всего подтома при создании снимка, а накопление блоков, которые изменились, но всё ещё нужны существующим снимкам.

Контрольные суммы и scrub в Btrfs

Btrfs хранит контрольные суммы данных и метаданных и сверяет их при чтении. Несовпадение позволяет обнаружить повреждение, которое иначе могло бы пройти незамеченным. Но обнаружить ошибку и исправить её не одно и то же.

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

Scrub проверяет данные и метаданные на соответствие контрольным суммам и выявляет ошибки чтения. Если найдена ошибка, а доступна исправная копия, проверка может использовать её для исправления. Без такой копии scrub обнаружит проблему, но не восстановит исходное содержимое. Контрольная сумма помогает понять, что блок повреждён; она не содержит самих данных и не может пересоздать их.

Здесь важно различать три вещи: обнаружение ошибки, исправление за счёт избыточной копии и резервное копирование. Scrub относится к проверке целостности и, при наличии исправной реплики, к самовосстановлению. Снимок хранит предыдущее состояние файлов в рамках той же файловой системы. Резервная копия нужна для восстановления после более широкого набора событий, включая отказ накопителя или удаление самого снимка.

Журнал ext4 и восстановление данных

Журнал ext4 нужен прежде всего для согласованности файловой системы после сбоя питания или аварийного завершения работы. Он помогает завершить либо отменить незавершённые изменения метаданных, чтобы структура каталогов и служебные данные не остались в противоречивом состоянии. Это снижает риск повреждения структуры, но не превращает журнал в архив прежних версий файлов.

В стандартном режиме data=ordered журналируются метаданные, а данные файлов не записываются в журнал как отдельная копия. Файловая система упорядочивает запись данных и метаданных так, чтобы уменьшить риск появления некорректной ссылки на ещё не записанное содержимое. После сбоя структура может быть восстановлена, однако журнал не обещает вернуть последние изменения содержимого файла.

Режим data=journal отправляет в журнал и данные, и метаданные. Такая схема даёт более строгую согласованность содержимого при сбое, но требует дополнительных операций записи и может снижать производительность. И в этом случае журнал не предназначен для восстановления удалённой версии файла спустя время: это механизм работы с незавершёнными операциями, а не история изменений.

У Btrfs снимки могут сохранить старое состояние файла, если снимок создан до изменения или удаления и его блоки доступны. У ext4 встроенного аналога снимка нет, поэтому прежнее состояние обычно ищут в резервной копии или во внешнем механизме снимков. Но наличие снимка Btrfs не даёт безусловной гарантии: он может не содержать нужную версию, быть удалён вместе с другими данными или зависеть от тех же блоков, которые повреждены.

Для извлечения данных с повреждённой Btrfs существует btrfs restore. Утилита пытается прочитать доступные метаданные и восстановить файлы в другое место. Это не откат по снимку и не обещание, что все файлы удастся вернуть: результат зависит от состояния метаданных и доступности данных. При проблемах с накопителем особенно важно не продолжать запись на него, поскольку новые операции могут затронуть ещё доступные блоки.

В ext4 для поиска и извлечения данных используют, среди прочего, debugfs и extundelete. Такие инструменты не превращают журнал в резервную копию и не гарантируют успех после перезаписи блоков. Возможность восстановления зависит от того, какие данные остались на устройстве и насколько сильно изменилась файловая система после удаления.

Выбор зависит от задачи, а не от одной цифры

Для баз данных, очередей и других нагрузок с высокой долей случайных операций стоит смотреть на результаты именно соответствующих тестов и повторять замеры на целевой конфигурации. В испытаниях Phoronix Btrfs уступала ext4 и XFS в SQLite с четырьмя параллельными базами и при случайном чтении блоков по 4 КиБ. Это весомый сигнал для похожей нагрузки, но не доказательство, что Btrfs будет медленнее на любой базе или любом накопителе.

Btrfs имеет смысл рассматривать там, где нужны снимки, reflink, сжатие и встроенная проверка данных по контрольным суммам. Эти возможности могут упростить работу с тестовыми средами, версиями данных и копиями файлов. Взамен приходится учитывать CoW, возможный рост занятого места из-за снимков и особенности выбранного профиля хранения.

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

Файловая система может поддержать согласованность, обнаружить повреждение или сохранить прежнее состояние. Резервная копия нужна для восстановления, когда этих возможностей недостаточно.

Именно поэтому выбор между ext4 и Btrfs не сводится к тому, какая система быстрее скопировала данные в одном тесте. Важнее сопоставить нагрузку с результатами замеров, понять, как будут использоваться снимки и сжатие, и заранее определить, откуда брать исправную копию при потере данных. Ни журнал ext4, ни контрольные суммы Btrfs, ни снимки не заменяют независимое резервное копирование.