Файловая система Bcachefs в Ubuntu, замеры скорости и проверка целостности

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

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

Автор проекта Кент Оверстрит прославился до Bcachefs модулем bcache, блочным кэшем для медленных дисков, который живёт в ядре с 2013 года. В 2015 году он объявил, что код кэша естественно дорос до полноценной файловой системы с копированием при записи, и поставил цель амбициознее некуда: возможности ZFS и Btrfs в связке со скоростью ext4 и XFS. Проект восемь лет зрел на стороне, затем патчи приняли в ядро 6.7, которое вышло в январе 2024-го. Первым крупным дистрибутивом со встроенной поддержкой стала Ubuntu 24.04 LTS на ядре 6.8, так что владелец свежей системы получал bcachefs прямо из коробки.

Дальше началась странная часть истории. Линус Торвальдс ещё в апреле 2024 года иронизировал по поводу зрелости кода, а в июне 2025-го после очередного спора о процессе принятия патчей объявил, что пути разработчика и ядра расходятся. В августе статус модуля в дереве ядра сменили с "поддерживается" на "сопровождается внешне", в сентябре проект заявил о переходе на схему DKMS, а начиная с выпуска 6.18 код в основной ветке больше не числится. Актуальные ядра основной ветки уже добрались до серий 7.x, и Bcachefs там нет. Модуль собирается из дерева проекта для ядер начиная с 6.16, утилиты для Debian и Ubuntu собирает собственный репозиторий проекта, а свежий выпуск инструментов носит номер 1.39.7. Формат данных на диске при этом остался прежним, и разделы, отформатированные ещё под ядро 6.8, читаются без переделок.

Установка bcachefs-tools и подготовка безопасного стенда в Ubuntu

Первым делом смотрим, с каким ядром работает система, командой uname -r, и от результата зависит план. На Ubuntu 24.04 с ядром 6.8 и на 25.10 с ядром 6.17 модуль уже внутри ядра, достаточно поставить утилиты:

sudo apt update
sudo apt install bcachefs-tools
bcachefs version

Если ядро 6.18 или новее, добавляем репозиторий проекта и ставим пакет вместе с модулем DKMS. Все команды выполняются в терминале Ubuntu от пользователя с правами sudo:

sudo install -d -m 0755 /etc/apt/keyrings
wget -qO- https://apt.bcachefs.org/apt.bcachefs.org.asc | sudo tee /etc/apt/keyrings/apt.bcachefs.org.asc > /dev/null
sudo chmod 0644 /etc/apt/keyrings/apt.bcachefs.org.asc
sudo tee /etc/apt/sources.list.d/apt.bcachefs.org.sources > /dev/null <<EOF
Types: deb deb-src
URIs: https://apt.bcachefs.org/$(. /etc/os-release && echo ${UBUNTU_CODENAME:-$VERSION_CODENAME})/
Suites: bcachefs-tools-release
Components: main
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/apt.bcachefs.org.asc
EOF
sudo apt update
sudo apt install bcachefs-tools

Пакет bcachefs-kernel-dkms подтягивается автоматически, а строка bcachefs version печатает номер выпуска инструментов, который должен совпасть с последним релизом. Для тренировки не обязательно жертвовать разделом: файл с образом и loop-устройство дают безопасный полигон, где ошибки ничего не стоят:

fallocate -l 20G ~/bcachefs-test.img
sudo losetup -f --show ~/bcachefs-test.img

Вторая команда напечатает имя устройства, например /dev/loop0. Все дальнейшие опыты идут на нём, а по завершении достаточно отвязать образ командой sudo losetup -d /dev/loop0 и удалить файл. На реальном диске схема та же, меняется только имя устройства.

Форматирование раздела со сжатием, метками и целями размещения

Минимальный вариант выглядит скромно, две команды и том готов:

sudo bcachefs format /dev/loop0
sudo mount -t bcachefs /dev/loop0 /mnt

Интерес начинается с опций. Следующая команда форматирует носитель с сжатием, двумя копиями метаданных и человеческой меткой тома, которую видно в выводе lsblk -f:

sudo bcachefs format \
  --fs_label=data-vault \
  --compression=zstd \
  --background_compression=zstd:10 \
  --metadata_replicas=2 \
  /dev/loop0

Разница между --compression и --background_compression тонкая, но заметная на практике. Первая сжимает каждый новый экстент сразу, вторая включает эвристику: горячие данные переписываются с высоким уровнем zstd:10, а холодные со временем пережимаются слабее, что экономит процессор при активной записи. Совсем отключить копирование при записи позволяет флаг --nocow, однако он заодно убирает контрольные суммы, сжатие и шифрование, и том теряет главное.

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

sudo bcachefs format /dev/sd[ab]1 \
  --label=ssd /dev/sda1 \
  --label=hdd /dev/sdb1 \
  --foreground_target=ssd \
  --promote_target=ssd \
  --background_target=hdd

Записи сначала оседают на быстром устройстве, фоновые процессы переносят их на медленное, а часто читаемые блоки возвращаются обратно. Устройство, работающее как кэш и не участвующее в подсчёте надёжности, добавляют с параметром --durability=0. Монтирование пары дисков требует перечисления через двоеточие:

sudo mount -t bcachefs /dev/sda1:/dev/sdb1 /mnt

Узлы B-дерева занимают по 256k по умолчанию, и на это стоит смотреть при настройке под базы данных. Поведение при обнаружении повреждений задаёт параметр --errors со значениями continue, ro и panic, для сервера обычно выбирают ro, чтобы система сама уходила в режим только чтения вместо тишины.

Контрольные суммы от crc32c до команды scrub и чтение суперблока

По умолчанию и данные, и метаданные защищает алгоритм crc32c, аппаратно ускоряемый на современных процессорах x86. Альтернативы задаются при форматировании: опции --data_checksum и --metadata_checksum принимают значения none, crc32c, crc64 и xxhash. На зашифрованных томах суммы превращаются в криптографические имитовставки chacha20/poly1305, а опция --wide_macs хранит их полные 128 бит вместо стандартных 80.

Убедиться, что том отформатирован как задумано, позволяет чтение суперблока:

sudo bcachefs show-super /dev/loop0

В выводе видны версия формата, метка, список устройств и все опции, включая тип контрольных сумм. Состояние работающей файловой системы показывает fs usage с флагом -h для читаемых размеров: команда печатает распределение данных и метаданных по устройствам, число реплик и свободное место.

Полную проверку целостности запускает scrub, и выполняется она на смонтированном томе:

sudo bcachefs scrub /mnt
sudo bcachefs scrub -m /mnt

Первая строка читает все файлы, пересчитывает суммы и при устранимом повреждении восстанавливает данные из второй реплики, вторая проверяет только метаданные. Пути повреждённых файлов scrub пишет в журнал ядра, поэтому рядом открывают dmesg -w. Плановая проверка без монтирования поручается fsck, причём в двух режимах: флаг -n только ищет ошибки и ничего не правит, флаг -p чинит автоматически без вопросов, флаг -f заставляет проверить даже том, помеченный чистым:

sudo bcachefs fsck -n /dev/loop0

После сбоя или замены диска за восстановление избыточности отвечает пара команд reconcile status и reconcile wait, они показывают очередь фоновой работы и дожидаются её завершения. Приятно и то, что часть опций меняется на лету: каталог /sys/fs/bcachefs/UUID/options/ принимает записи прямо во время работы тома, без перемонтирования.

Замеры скорости через fio и живые счётчики fs top

Для честных цифр понадобится fio, ставится одной строкой: sudo apt install fio. Методика простая: одинаковые прогоны выполняются на bcachefs и на ext4 в тех же условиях, меняется ровно одна переменная, остальное фиксируется, и каждый профиль повторяют трижды. Последовательную запись крупными блоками меряет такой профиль:

fio --name=seqwrite --filename=/mnt/fio.bin --size=4G \
  --rw=write --bs=1M --direct=1 --ioengine=libaio \
  --iodepth=32 --time_based --runtime=60 --group_reporting

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

fio --name=randrw --filename=/mnt/fio.bin --rw=randrw \
  --rwmixread=70 --bs=4k --direct=1 --ioengine=libaio \
  --iodepth=32 --numjobs=4 --time_based --runtime=60 \
  --group_reporting

В отчёте fio интересны три вещи: IOPS, пропускная способность и процентили задержки в строках lat, причём именно 99-й перцентиль показывает, как система ведёт себя под хвостом нагрузки. Между прогонами кэш страниц сбрасывают:

sync
echo 3 | sudo tee /proc/sys/vm/drop_caches
rm /mnt/fio.bin

По опыту владельцев тестовых стендов, на типовых последовательных операциях Bcachefs держится рядом с ext4, чего и добивались при проектировании. Цифры уплывают в двух местах. Сжатие zstd переносит нагрузку с диска на процессор и на слабых четырехъядерных машинах срезает пик записи, зато на HDD-массиве экономит столько операций ввода-вывода, что выигрыш перекрывает потери. Второе узкое место, синхронные мелкие записи с fsync, привычные для баз данных; здесь выручает set-file-option, который вешает флаг --nocow на отдельные каталоги, пусть и ценой отказа от сумм и сжатия в них.

Пока тесты бегут, вторым терминалом наблюдают живые счётчики:

sudo bcachefs fs top /mnt -n 5 -d 2

Команда печатает пять сэмплов с шагом 2 секунды: очереди запросов, объёмы чтения и записи по устройствам, работу фоновой перезаписи. Смотреть, как эстафета передачи данных переходит с SSD на HDD, поучительнее любых диаграмм: первые секунды записи принимает быстрый target, затем данные спокойно утекают на медленный диск.

Вердикт для домашнего сервера на текущий год

Картина складывается из трёх фактов. Функциональность у проекта на уровне лучших образцов: снимки, сжатие, шифрование, erasure coding без знаменитой дыры записи RAID5, целостность данных с самовосстановлением. Стабильность держится на честном слове: сами разработчики описывают состояние проекта как рабочее, с небольшим сообществом, а у инженеров ядра были претензии к качеству кода. Статус вне дерева ядра означает, что обновления модуля теперь едут отдельно от системы, как у ZFS, и обновление ядра Ubuntu может на время оставить том без модуля, пока DKMS не соберёт новый.

Практика подсказывает простую логику:

1. Корень системы оставляйте на ext4, а Bcachefs выделяйте отдельным разделом под данные, чтобы сбой эксперимента не трогал загрузку;
2. Медиатеку, архивы и резервные копии отдавайте смело, там сжатие zstd и снимки subvolume snapshot окупаются мгновенно;
3. Комбинацию SSD плюс HDD собирайте через три цели размещения, это самый заметный выигрыш проекта на домашнем железе;
4. Включайте data_replicas=2 хотя бы для важных каталогов, самовосстановление работает только при второй копии;
5. Держите ядро в диапазоне, который поддерживает модуль, проверяйте сборку DKMS до перезагрузки и обкатывайте обновления сначала на тестовой машине.

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

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