Средний

7 мин

0

Вынос со скандалом 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:

Compression:
type            compressed  uncompressed
zstd                 8.00M          512M
incompressible        256M          256M

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

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. Создание и удаление 10 000 мелких файлов замерялись отдельно обычным 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 показала, что часть метаданных уже требует восстановления реплик:

undegraded    -1x
2x:        548M  3.50M
Pending reconcile:
replicas:              0     1.75M
high_priority:         0     1.75M

В 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 уже интересно гонять. Для продакшена или единственной копии важных данных — только после собственных аварийных тестов и с нормальными бэкапами.