Bcachefs после снятия experimental: гоняем тесты на Ubuntu 26.04⁠⁠

Вынос со скандалом Bcachefs из mainline-ядра Linux в конце 2025 года (начиная с релиза 6.18) проект не похоронил. Напротив, это явно подстегнуло мейнтейнера к жесткой дисциплине. Спустя 7 месяцев проект перешел на DKMS-модель и официально снял статус experimental.

Развернул тестовую ВМ в Proxmox, чтобы посмотреть на эксплуатационный UX: как ставится, как ведет себя при отказе дисков и стоит ли тащить в homelab или прод.

Дисклеймер. Это синтетические тесты, а не академический бенчмарк (на виртуалке поверх ZFS тестировать скорость - такое себе). Цель - проверить работу базовых функций, диагностику и поведение при аварии.

1. Установка и DKMS-нюансы

Тест проводился на Ubuntu 26.04 с ядром 7.0.0-22-generic. Штатного модуля в ядре дистрибутива нет, так что идем в официальный репозиторий за DKMS:

# Добавляем репозиторий apt.bcachefs.org (unstable / bcachefs-tools-release) и затем ставим всю обвязку

sudo apt install bcachefs-tools bcachefs-kernel-dkms fio btrfs-progs

По итогу получаем собранный модуль (bcachefs.ko.zst версии 1.38.6), и dmesg ожидаемо сыплющий ворнингами про tainting kernel и verification failed. Ну это просто надо иметь ввиду - теперь вы живете на внешнем модуле, и при каждом обновлении ядра нужно будет пристально следить за DKMS.

bcachefs: loading out-of-tree module taints kernel

bcachefs: module verification failed: signature and/or required key missing - tainting kernel

bcachefs: filldir64 fastpath disabled: struct layout unverified for this kernel

2. Базовый single-disk сценарий

Первый тест был максимально тупой и прямолинейный:

1. Создать ФС на одном диске.

2. Смонтировать.

3. Записать файл 1 GiB и 5000 мелких файлов.

4. Запустить usage/scrub.

5. Размонтировать и выполнить offline check.

Для Bcachefs:

sudo bcachefs format -f -L bcf_single /dev/sdb

sudo mount -t bcachefs -o noatime /dev/sdb /mnt/bcf

sudo bcachefs fs usage -h -a /mnt/bcf

sudo bcachefs scrub /mnt/bcf

sudo bcachefs fsck -n -f /dev/sdb

Для Btrfs:

sudo mkfs.btrfs -f -L btr_single /dev/sdc

sudo mount -t btrfs -o noatime /dev/sdc /mnt/btr

sudo btrfs filesystem usage -T /mnt/btr

sudo btrfs scrub start -B /mnt/btr

sudo btrfs check --readonly /dev/sdc

На этом этапе всё скучно, единственная практическая ценность тут - набор команд для создания ФС, может кому пригодится как шпаргалка.

Можно еще отдельно сказать про команды Bcachefs. Они непривычны, но в целом на удивление логичны: вместо mkfs.bcachefs используется bcachefs format, диагностика идёт через bcachefs fs usage, проверка через bcachefs fsck.

3. Сжатие

Для проверки сжатия использовал простой набор:

1. zero-512m.bin, 512 MiB нулей.

2. random-256m.bin, 256 MiB случайных данных.

Bcachefs создавалась сразу с zstd:

sudo bcachefs format -f -L bcf_zstd --compression=zstd /dev/sdb

Btrfs монтировалась с compress=zstd:

sudo mount -t btrfs -o noatime,compress=zstd /dev/sdc /mnt/btr

У Bcachefs понравилась отдельная секция в fs usage:

Итоговое использование места:

Bcachefs - около 283 MiB

Btrfs - около 274 MiB

Обе ФС отработали отлично (нули сжали, рандом пропустили). Разница в несколько мегабайт тут не имеет особого смысла.

Из интересного - у Bcachefs утилита fs usage выдает шикарную и очень наглядную статистику по сжатым/несжимаемым данным прямо в консоль.

4. Снапшоты

Снапшоты проверял простым бытовым сценарием:

1. Создать subvolume.

2. Записать state.txt со значением original.

3. Создать read-only snapshot.

4. В живом subvolume поменять файл на changed.

5. Прочитать файл из snapshot.

Bcachefs:

bcachefs subvolume create /mnt/bcf/subv

bcachefs subvolume snapshot -r /mnt/bcf/subv /mnt/bcf/snap1

Btrfs:

btrfs subvolume create /mnt/btr/subv

btrfs subvolume snapshot -r /mnt/btr/subv /mnt/btr/snap1

Результат у обеих ФС одинаковый:

live=changed

snapshot=original

Здесь ноль сюрпризов. Снапшоты работают так, как от CoW-ФС и ожидаешь.

5. Производительность fio и мелкие файлы

Теперь к цифрам. Ещё раз: это синтетические тесты внутри одного сомнительного стенда.

Параметры fio:

single disk

без сжатия

sequential read/write: bs=1M, size=2G

random write: bs=4k, numjobs=4, iodepth=16, runtime=30

Первые три строки ниже - это fio. Создание и удаление 10000 мелких файлов замерялись отдельно обычным shell-сценарием: создание дерева файлов и последующий rm -rf этого дерева.

Результаты:

На этом стенде Bcachefs заметно быстрее на последовательной записи, random write 4K и создании мелких файлов. Btrfs, наоборот, быстрее на последовательном чтении и чуть быстрее удаляет дерево мелких файлов.

Само собой всё это автоматически не приводит нас к выводу, что Bcachefs быстрее Btrfs. Всё таки подложка в виде Proxmox/ZFS может сильно влиять на такие цифры. Но как лабораторный результат - как минимум любопытно.

Отдельный нюанс: во время нагрузки у Bcachefs в dmesg появилась строка:

bcachefs (sdb): bch2_journal_flush_seq stuck? Waited 10s for seq 32

После этого ФС нормально размонтировалась и прошла проверки. Но при эксплуатации это сообщение нельзя просто игнорировать. Его стоит отдельно разбирать при повторных тестах.

6. Multi-device

Одна из причин вообще смотреть на Bcachefs - обещание функциональности уровня современных CoW-ФС с более гибкой моделью устройств.

Bcachefs с двумя копиями данных и метаданных создаётся так:

bcachefs format -f -L bcf_raid1 --replicas=2 /dev/sdb /dev/sdc

После записи 512 MiB полезной нагрузки bcachefs fs usage показал ожидаемую репликацию:

Btrfs RAID1 создавался привычно:

mkfs.btrfs -f -d raid1 -m raid1 -L btr_raid1 /dev/sdb /dev/sdc

У него всё ожидаемо отображается через Data ratio: 2.00 и Metadata ratio: 2.00.

Нюанс в терминологии: у Bcachefs модель --replicas=2 читается проще. Мы описываем желаемое количество копий, а не выбираем отдельные RAID-профили для data и metadata. Для админа это вполне приятная деталь.

7. Потеря диска на живую

Ну и само собой важная часть для любой multi-device ФС нифига не красивая таблица fio, а поведение при отказе.

Сначала пробовал имитировать отказ изнутри гостевой ОС через /sys/block/*/device/delete и device/state=offline. В этой ВМ метод оказался ненадёжным: устройство либо оставалось видимым, либо состояние быстро возвращалось в running.

Поэтому финальный тест делал через QMP hot-unplug на уровне Proxmox/QEMU. Постоянную конфигурацию ВМ не менял, удалял только live-устройство.

Bcachefs

Сценарий:

1. Bcachefs на /dev/sdb и /dev/sdc.

2. Форматирование с --replicas=2.

3. Запись 256 MiB payload.

4. QMP device_del scsi2, то есть удаление второго диска.

5. Проверка чтения старого файла и запись нового файла.

После hot-unplug /dev/sdc исчез из lsblk. Чтение и запись продолжили работать:

/mnt/bcf/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/bcf/after-qmp-hotunplug.txt

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

В dmesg появились ожидаемые ошибки по удалённому устройству:

bcachefs: error writing btree node ... sdc io: BLK_STS_OFFLINE

bcachefs (sdc): offline from block layer

bcachefs: error writing btree node ... sdc io: BLK_STS_REMOVED

Практический вывод: ФС осталась рабочей, данные читались, новая запись прошла. При этом состояние явно деградировало и требует дальнейшего reconcile/восстановления. Собственно, именно это и хотелось увидеть от теста.

Btrfs

Для Btrfs аналогичный сценарий делал на другой паре дисков:

1. Btrfs RAID1 на /dev/sdd и /dev/sde.

2. Так же запись 256 MiB payload.

3. QMP device_del scsi4.

4. Проверка чтения и запись нового файла.

После удаления /dev/sde ФС тоже продолжила работать:

/mnt/btr/payload.bin: OK

-rw-rw-r-- 1 user user 20 ... /mnt/btr/after-qmp-hotunplug.txt

btrfs filesystem usage -T показал missing device:

WARNING: failed to get device size for /dev/sde: No such file or directory

Device missing: 20.00GiB

В dmesg появились ошибки записи на удалённое устройство:

BTRFS error (device sdd): bdev /dev/sde errs: wr 1, rd 0, flush 0, corrupt 0, gen 0

BTRFS warning (device sdd): lost super block write due to IO error on /dev/sde (-5)

BTRFS error (device sdd): error writing primary super block to device 2

В этом конкретном сценарии обе ФС повели себя адекватно: RAID1-подобная конфигурация пережила потерю одного диска на живую, данные остались читаемыми, запись продолжилась.

8. Что там по UX

Понравилось в Bcachefs:

1. bcachefs fs usage -h -a очень информативен.

2. Хорошо видно data/metadata, compression, btree и состояние устройств.

3. Модель --replicas=2 читается проще, чем отдельные профили -d raid1 -m raid1.

4. Снапшоты и subvolume-команды выглядят логично.

5. Потерю одного устройства при репликации ФС пережила.

Минусы:

1. Вместо нормальной поставки в составе ядра - поставляется как DKMS-модуль со всеми вытекающими (вообще надо было постараться настолько сильно выбесить мейнтейнеров ядра своим стилем разработки, чтоб тебя со скандалом вып*здили из mainline)

2. В dmesg был warning про bch2_journal_flush_seq stuck.

3. Сценарий возврата или замены диска после hot-unplug надо тестировать отдельно.

У Btrfs главный плюс скучный, но весомый: он давно есть в дистрибутивах, хорошо документирован, привычен и в принципе практически стабилен.

Итоги

1. Bcachefs после снятия experimental уже имеет смысл тестировать в homelab.

2. В базовых сценариях ФС отработала нормально: создание, монтирование, scrub/fsck, сжатие, снапшоты, multi-device.

3. На этом стенде Bcachefs хорошо выступила на записи и мелких файлах, но это синтетические тесты.

4. Потерю одного диска при --replicas=2 Bcachefs пережила: данные читались, запись продолжалась, диагностика показала деградацию.

Если резюмировать, то основные вопросы пока не столько к самой ФС, сколько к эксплуатационной обвязке: DKMS, обновления ядра, загрузка модуля и восстановление после отказов.

ИМХО, для лаборатории, тестового NAS, домашнего стенда и удовлетворения инженерного любопытства - да, Bcachefs уже интересно гонять. Для продакшена или единственной копии важных данных - только после собственных аварийных тестов и с нормальными бэкапами.