LINUX.ORG.RU

Файловая система Bcachefs официально перестала быть экспериментальной

 , , , ,


0

2

Кент Оверстрит (Kent Overstreet) опубликовал выпуск файловой системы Bcachefs 1.38.6 и объявил об официальном снятии с проекта метки экспериментальной разработки. Последнее время число поступающих сообщений о проблемах сократилось, а выявляемые ошибки стали менее серьёзными и замысловатыми.

Выпуск охватывает два пакета: bcachefs-kernel-dkms с модулем ядра, собираемым при помощи системы DKMS (Dynamic Kernel Module Support), и bcachefs-tools с запускаемой в пространстве пользователя утилитой bcachefs, реализующей команды для создания (mkfs), монтирования, восстановления и проверки ФС. Пакеты собраны для Debian, Ubuntu, Arch Linux и ожидаются для Fedora, openSUSE и NixOS. DKMS-модуль поддерживает работу с ядрами Linux, начиная с 6.16.

Несмотря на непримечательный номер версии, обусловленный отсутствием изменений в дисковом формате, выпуск 1.38.6 включает ряд серьёзных оптимизаций производительности. В код для работы со структурами в формате btree, журналирования и обеспечения работы файловой системы внесено около 200 изменений, повышающих производительность. Логика подтверждения транзакций ужата в 4КБ машинного кода, добавлены оптимизации для исключения возникновения конкурирующих блокировок (lock contention) при работе с btree, полностью избавлен от блокировок процесс сброса состояния журнала (journal flush).

На сервере с 48-ядерном CPU AMD в Bcachefs удалось добиться пропускной способности 16.5 Гбайт/с при запуске 48 клиентов dbench (для сравнения в XFS получен результат в 16 Гбайт/с). Подготовлены, но отложены до следующего релиза, патчи, доводящие производительность в тестах dbench до 19 Гбайт/с (данные патчи требуют дополнительного тестирования или изменения дискового формата). При тестировании утилитой fio (github.com) производительность Bcachefs составила 700 операций в секунду при выполнении операций случайной записи 4-килобайтными блоками (XFS демонстрирует в этом тесте миллион операций в секунду, при том, что XFS ограничивается ремапингом блоков, а Bcachefs обрабатывает полный цикл CoW (Copy-on-Write) с проверкой контрольных сумм и обновлением структуры btree).

Помимо оптимизаций в выпуске Bcachefs 1.38.6 реализована поддержка подключения до 255 устройств к одной ФС. В репозитории apt.bcachefs.org началось формирование пакетов для Ubuntu 26.04. Инфраструктура непрерывной интеграции и автоматизированного тестирования переведена на проверку сборок на базе DKMS. В следующие несколько месяцев планируется сосредоточить внимание на оптимизации работы файловой системы с несколькими устройствами хранения.

Кроме того, продолжается работа по переписыванию кода на языке Rust. Отмечается, что поддержка Rust в ядре достигла знакового момента — все значительные дистрибутивы при формировании пакетов с ядром 7.0 по умолчанию активировали настройку CONFIG_RUST для сборки ядра с поддержкой Rust. В проекте Bcachefs на Rust уже переписан набор утилит bcachefs-tools, запускаемый в пространстве пользователя, включая реализацию API для работы со структурами btree. В следующем релизе планируется интегрировать подготовленные обвязки на Rust в DKMS-модуль ядра и начать переписывание базового кода Bcachefs. Предполагается, что использование Rust повысить гибкость, стабильность и удобство работы с кодом, сделает проект более интересным для молодых инженеров и позволит в будущем реализовать формальную верификацию надёжности.

Проектом Bcachefs развивается файловая система, нацеленная на сочетание расширенной функциональности, свойственной Btrfs и ZFS, и уровня производительности, надёжности и масштабируемости, характерного для XFS. Bcachefs поддерживает такие возможности, как включение в раздел нескольких устройств, многослойные раскладки накопителей (нижний слой с часто используемыми данными на базе быстрых SSD, а верхний слой с менее востребованными данными из жестких дисков), репликация (RAID 1/10), кэширование, прозрачное сжатие данных (режимы LZ4, gzip и ZSTD), срезы состояния (снапшоты), верификация целостности по контрольным суммам, коды коррекции ошибок, хранение информации в зашифрованном виде (используются ChaCha20 и Poly1305).

Из значительных нововведений, добавленных в Bcachefs за последние месяцы, упоминаются:

  • Механизм reconcile (rebalance_v2), который в отличие от режима rebalance позволяет выполнить ребалансировку не только данных (например, реплицирование нескольких копий на разные накопители), но и метаданных в ФС (например, для переноса метаданных после добавления в пул дополнительного накопителя). Reconcile применим для всех операций ввода/вывода, а не только для операций фонового копирования и сжатия. В reconcile автоматически учитываются изменения настроек устройств и сразу перереплицируются деградировавшие данные и метаданные.
  • Поддержка кодов коррекции ошибок, позволяющих восстанавливать повреждённые данные по аналогии с RAID 5/6. Реализация основана на кодировании Рида-Соломона, способном исправить до N ошибок в страйпе (stripe) при наличии N избыточных блоков. Обеспечено автоматическое восстановление деградировавших страйпов. Возможность применения кодов восстановления применима в конфигурациях с накопителями разного размера.

>>> Источник: OpenNET

★★★★★

Проверено: CrX ()

Звучит здорово. Если бы ещё обратно в ядро взяли, и автор на этот раз вёл себя прилично, стало бы прям совсем замечательно.

CrX ★★★★★
()

Подождать еще лет 5 на «стабилизацию после стабилизации», и можно рассматривать как вариант)

wandrien ★★★★
()

Кроме того, продолжается работа по переписыванию кода на языке Rust. Отмечается, что поддержка Rust в ядре достигла знакового момента — все значительные дистрибутивы при формировании пакетов с ядром 7.0 по умолчанию активировали настройку CONFIG_RUST для сборки ядра с поддержкой Rust. В проекте Bcachefs на Rust уже переписан набор утилит bcachefs-tools, запускаемый в пространстве пользователя, включая реализацию API для работы со структурами btree. В следующем релизе планируется интегрировать подготовленные обвязки на Rust в DKMS-модуль ядра и начать переписывание базового кода Bcachefs. Предполагается, что использование Rust повысить гибкость, стабильность и удобство работы с кодом, сделает проект более интересным для молодых инженеров и позволит в будущем реализовать формальную верификацию надёжности.

А… понятно.

Ну тогда еще к этим пяти годам надо еще прибавить время переписывания на Раст.

wandrien ★★★★
()
Ответ на: комментарий от CrX

на этот раз

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

firkax ★★★★★
()
Ответ на: комментарий от REDDERa

Но зачем если оно через тот же екст4 драйвер теперь работает?

ya-betmen ★★★★★
()

производительность Bcachefs составила 700 операций в секунду

Слишком уж Линус добр. Гнать таких вредителей-рустаманов нужно нещадно, мокрой тряпкой!

Никому не попадался тест хотя бы на 7.0-ядре? А то этому уже год

hargard ★★★
()
Ответ на: комментарий от REDDERa

Да пофиг, мне нужно старое и предсказуемое…ext2:))

Она без журнала. ext4 наше всё.

Не так давно, настраивая новый ноут, думал в чём бы корень форматнуть. И с удивлением прочитал, что ext4 надёжнее всего современного – в т.ч. не только дефолтной в генте xfs (а поначалу чуть было её не воткнул: гента ж, плохого не посоветуют), но даже построенной на снапшотах f2fs (это вообще как так?!).

dimgel ★★★★★
()
Последнее исправление: dimgel (всего исправлений: 1)
Ответ на: комментарий от hargard

Откуда гнать? Разработка bcachefs уже давно out-of-tree ведётся.

SeTSeR
()
Ответ на: комментарий от dimgel

Для меня xfs - до сих пор ФС для эффективного хранения больших файлов, вроде видео. Ну и надо не забывать, что разделы с ней можно только увеличивать. Как-то раз огреб неприятностей, когда неправильно разбил диск и потом хотел изменить его. Но там вендор ставил на сервера xfs изначально, иначе я бы сам взял более популярную ext4.

skyman ★★★★★
()

Последнее время число поступающих сообщений о проблемах сократилось

Просто люди поняли, что это очередная вечная бета, так же как и с btrfs, и перестали юзать ее)

iron ★★★★★
()
Ответ на: комментарий от CrX

и автор на этот раз вёл себя прилично

Без шансов - такие не лечатся и слов не понимают. Поэтому и проект совершенно не интересен - доверять данные ФС с bus factor = 1 просто бессмысленно.

zabbal ★★★★☆
()
Ответ на: комментарий от zabbal

Практика показывает что бас фактор вообще никак не влияет на то можно ли доверять данные фс.

ya-betmen ★★★★★
()
Последнее исправление: ya-betmen (всего исправлений: 1)

Подготовлены, но отложены до следующего релиза, патчи, доводящие производительность в тестах dbench до 19 Гбайт/с (данные патчи требуют дополнительного тестирования или изменения дискового формата).

перестала быть экспериментальной

ЛАДНО.

thesis ★★★★★
()

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

Почти стабильная ФС это как почти не беременная девушка.

btrfs это тоже касается. Что это вообще за критерии такие, «вроде теперь не глючит»? Я что-то не припоминаю, чтобы у ext4 или XFS были вообще периоды, когда потери данных при работе считались нормой, ведь еще не доделали.

Vsevolod-linuxoid ★★★★★
()
Ответ на: комментарий от CrX

А btrfs чем не нормально?

Какие преимущества получит пользователь?

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

wandrien ★★★★
()
Ответ на: комментарий от wandrien

Ну тогда еще к этим пяти годам надо еще прибавить время переписывания на Раст.

И ещё 2x для переписывания обратно на C

Ксати никто не упомянул, что второй основной разработчик — это инстанс Claude под именем Proof of Concept, которой прикрутили долговременную память на текстовых файлах.

Xenius ★★★★★
()
Последнее исправление: Xenius (всего исправлений: 2)
Ответ на: комментарий от wandrien

Похоже, что нужно вливаться в струю. Пошёл переписывать свои поделки с пхп на раст.

troizet
()
Ответ на: комментарий от Xenius

второй основной разработчик — это инстанс Claude

У меня давно уже крутится в голове идея наговнякать нейронкой файловую систему (соответствующего качества) и обозвать ее VibeFS. И сразу гигантский потенциал для хейтерского названия WipeFS прилагается.

liksys ★★★★
()
Ответ на: комментарий от liksys

Была вроде какая-то ОС, целиком так наговняканная.

wandrien ★★★★
()
Ответ на: комментарий от hargard

700 операций в секунду

Там очевидная опечатка в переводе.

В оригинальной новости 700 тысяч операций в секунду против миллиона у XFS.

Учитывая более сложный формат хранения, нормальный трейдофф.

wandrien ★★★★
()
Ответ на: комментарий от wandrien

А btrfs чем не нормально?

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

Какие преимущества получит пользователь?

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

CrX ★★★★★
()
Ответ на: комментарий от CrX

Ясно.

Про фрагментацию появляются вопросы:

  • Насколько это критично на SSD?
  • Не проще допилить АЛГОРИТМЫ работы драйвера btrfs (возможно с введением дополнительных структур данных на диске, если потребуется), чем создавать новую ФС для снижения фрагментации?
  • Реально на btrfs такая страшная фрагментация? Мне вот попадались как утверждения об этом, так и том, что ситуация по фрагментации была улучшена. Кому верить не знаю, сам я каких-то тестов не проводил, и длительного опыта использования не имею.

В любом случае, что я понял в ходе использования CoW ФС (btrfs), что тут не получится «поставил по дефолту и забыл», а нужно немного думать, как разбить на подтома, где выборочно выключить CoW и т.п. Более сложная модель данных требует более вдумчивого планирования. В данном случае «абстракция протекает», не получается получить фичи бесплатно, не повышая сложность для пользователя.

Про сабж:

Что ж, я как практик и скептик, смотрю на то, насколько эти вещи реализуемы в жизни.

Не вникал в устройство сабжа, слышал только, что автор проделал большую работу над ошибками на фоне btrfs.

Но:

  • Практическая стабильность и восстановимость ФС зависит от качества и зрелости кода, а также инструментов восстановления не меньше, чем от структур данных.
  • Сабж пытается залезть в переполненный вагон, где поляну делят ext4, XFS, btrfs и ZFS, каждая со своей достаточно понятной нишей. Чтобы вытеснить btrfs нужно быть не просто лучше, нужно быть ЗАМЕТНО лучше, преимущества должны быть прям наглядны.
  • Автор не умеет кооперироваться с сообществом. Если бы это был проект уровня файлового менеджера - не проблема. Может так даже лучше, сделал бы уникальный продукт без оглядки на остальных. Для ФС – проблема.
  • Если ФС не в дереве ядра, требуются более существенные усилия для привлечения разработчиков и пользователей. И здесь два предыдущих пункта становятся критичны.
  • Заявления, что код будет переписан на Rust, и что может потребоваться изменение дискового формата ОДНОВРЕМЕННО с новостью о стабилизации - ну это не серьёзно. После такого и возникает мысль «отложим лет на пять, а там видно будет». Это в дополнение к тому, что у автора нет ясной картины релиз-циклов в голове, из-за чего его код из ядра и выкинули.

Лично я долго сидел на стеке LVM + ext4, и только относительно недавно стал переползать на btrfs, когда она уже не просто стабилизировалась, а «достаточно протухла». Это ж не очередной аудиоплеер, спешка в таких вопросах ни к чему.

wandrien ★★★★
()
Последнее исправление: wandrien (всего исправлений: 1)
Ответ на: комментарий от wandrien

начать переписывание базового кода Bcachefs

Это ФС не для админов. Она не для того, чтобы ей пользоваться, она для программистов, чтобы руки всегда были заняты делом.

mamina_radost
()
Ответ на: комментарий от wandrien

Не проще допилить АЛГОРИТМЫ работы драйвера btrfs

У меня даже есть идея на какой язык их можно переписать…

mamina_radost
()
Ответ на: комментарий от wandrien

Мне кажется что сильная фрагментация неизбежна при использовании COW.

ptah_alexs ★★★★★
()
Ответ на: комментарий от wandrien

Насколько это критично на SSD?

Вообще не критично. Но на SSD не знаю как кого, а меня и ext4 более чем устраивает. Часть продвинутых фич ФС интересны как раз в разрезе HDD. Например, прозрачное сжатие зачастую может сэкономить не только место, но и повысить скорость загрузки контента, потому что декомпрессия дешёвая, а данных с медленного носителя читается меньше. Я так для игр SqaushFS использую. При загрузке с HDD не только место экономит, но и загрузки в игре становятся быстрее, иногда раза в полтора.

Не проще допилить АЛГОРИТМЫ работы драйвера btrfs (возможно с введением дополнительных структур данных на диске, если потребуется), чем создавать новую ФС для снижения фрагментации?

Насколько я понимаю, не проще. Это именно часть устройства ФС как таковой.

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

Здесь я в той же позиции, что и ты. У меня тоже нет длительного опыта использования (а тот не длительный, что есть, так себе, но он правда и был давно).

Практическая стабильность и восстановимость ФС зависит от качества и зрелости кода, а также инструментов восстановления не меньше, чем от структур данных.

В целом согласен. Меньше или не меньше — вопрос дискуссионный, но да, от них тоже зависит как минимум в весьма значимой степени.

Сабж пытается залезть в переполненный вагон, где поляну делят ext4, XFS, btrfs и ZFS, каждая со своей достаточно понятной нишей. Чтобы вытеснить btrfs нужно быть не просто лучше, нужно быть ЗАМЕТНО лучше, преимущества должны быть прям наглядны.

Частично согласен. Но я бы сказал, что проблема здесь больше в инфантилизме автора, нежели технических моментах. Я полагаю (хотя полной уверенности у меня нет), если бы сабж не выперли из ядра, и при этом не было бы каких-то ярких факапов, он довольно быстро бы вытеснил btrfs по крайней мере для новых установок. btrfs сам по себе ещё не укоренился достаточно, и вечно в этом полуэкспериментальном статусе, да и критики в его адрес и желания просто не связываться и «скипнуть» до появления сабжа было довольно много. Поэтому я думаю, если бы автор был поадекватнее именно как человек и умел работать в команде нормально, то сабж, конечно, вряд ли сильно потеснил бы ext4 и XFS, но вот btrfs если не прям совсем вытеснить, то сильно потеснить и превзойти вполне мог бы, причём возможно даже довольно быстро.

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

Полностью согласен.

Если ФС не в дереве ядра, требуются более существенные усилия для привлечения разработчиков и пользователей. И здесь два предыдущих пункта становятся критичным.

Снова полностью согласен (примерно про то же собственно и отписал в своём первом сообщении в этой теме).

Заявления, что код будет переписан на Rust, и что может потребоваться изменение дискового формата ОДНОВРЕМЕННО с новостью о стабилизации - ну это не серьёзно. После такого и возникает мысль «отложим лет на пять, а там видно будет». Это в дополнение к тому, что у автора нет ясной картины релиз-циклов в голове, из-за чего его код из ядра и выкинули.

И здесь не могу не согласиться. Не то чтобы это было бы какой-то огромной проблемой само по себе. Но именно в совокупности с остальным не добавляет оптимизма.

CrX ★★★★★
()
Последнее исправление: CrX (всего исправлений: 2)
Ответ на: комментарий от CrX

Я тоже помню, как в сообществе был настрой «щас сделают как btrfs, только нормально». Что btrfs так и не стала общепринятой, ты прав. Так что было реально заменить.

А потом Кент стал чудить.

Примерно в то же время, когда Линус пригрозил выкинуть bcachefs из ядра, я решил, что хватит сидеть на ext4, и надо попробовать частичную миграцию на btrfs. Потому что других вариантов всё равно в обозримом будущем не будет, походу.

wandrien ★★★★
()
Ответ на: комментарий от CrX

Если прям совсем кратко и по-простому: «это как btrfs, только сразу нормально

, но пока еще нет".

MoldAndLimeHoney ★★★
()

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

kirill_rrr ★★★★★
()
Ответ на: комментарий от kirill_rrr

вместо того чтобы быть простой прослойкой для работы гибридного диска из устройств с разными скоростями

А кто тебе вообще сказал, что она должна была быть ею? Чел изначально пилил свой ZFS с шахматами и поэтессами.

liksys ★★★★
()
Последнее исправление: liksys (всего исправлений: 1)
Ответ на: комментарий от kirill_rrr

Bcache гугл пилил для своих нужд. А bcachefs Кент начал делать, уволившись из гугла, это больше чем десять лет назад произошло. Он изначально и пилил этот проект, как файловую систему, в отличие от bcache.

liksys ★★★★
()
Ответ на: комментарий от zabbal

ФС с bus factor = 1

там же теперь еще его электронная подруга

akho ★★
()
Ответ на: комментарий от Vsevolod-linuxoid

Я что-то не припоминаю, чтобы у ext4 или XFS были вообще периоды, когда потери данных при работе считались нормой

Ты не застал времена, когда при внезапном ребуте XFS забивала файлы нулями ?

vasya_pupkin ★★★★★
()

«перестала быть», но в ядре ее нет, так?

sunjob ★★★★★
()
Ответ на: комментарий от vasya_pupkin

Ты не застал времена, когда при внезапном ребуте XFS забивала файлы нулями ?

Разве это уже не так?

theurs ★★
()

ЗОЧЕМ ЭТО НУЖНО, когда для моментальных снимков точек восстановления «Снаппер», есть бтрфс для корня, а для файловых помоек и хомяка — есть экст4 с кейсфолдом (?)

Set440 ★★
()
Для того чтобы оставить комментарий войдите или зарегистрируйтесь.