При обсуждении очередной порции исправлений, предложенных для включения в ядро 6.11-rc5 автором Bcachefs, Линус Торвальдс написал, что начинает сожалеть о том, что принял файловую систему Bcachefs в состав ядра. Недовольство Торвальдса связано с тем, что Кент Оверстрит (Kent Overstreet), автор Bcachefs, на стадии финальных кандидатов в релизы, присылает слишком объёмные исправления, которые по сути, не только исправляют ошибки, но и продолжают развитие функциональности, при том, что функциональные изменения допускаются только на начальной стадии разработки новой ветки, а на стадии rc5 принимаются только отдельные небольшие исправления, размер которых желательно не должен превышать 100 строк кода.

Присланный для Bcachefs патч, в котором было добавлено 1309 строк и удалено 671 строк в 39 файлах, помимо исправления ошибок включал два значительные изменения: поддержку новой структуры данных для управления списком свободных элементов в кэше и возможность преобразования хэш-таблиц для кэша. Новая структура была добавлена для избавления от лишних блокировок кэша и исключения ситуаций, которые могут привести к конфликтам блокировок при многопоточных нагрузках.

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

«Хватит. Последний pull-запрос также был большим. Данный pull-запрос тоже слишком объёмный, затрагивает вещи, не относящиеся к Bcachefs, и даже отдалённо не является какой-то регрессией. В какой-то момент «исправление чего-то» просто превращается в разработку, и это тот самый момент. Никто в здравом уме не использует Bcachefs и не ожидает от него стабильности, поэтому каждый пользователь — это область экспериментов. Патчи Bcachefs стали своего рода «большой разработкой во время цикла подготовки релиза, а не до него», до такой степени, что я начинаю сожалеть о принятии Bcachefs. Если Bcachefs не может нормально работать в соответствии с графиком разработки основного (upstream) ядра, возможно, его не должно быть в основном ядре. Это уже выходит за рамки смешного».

Кент Оверстрит ответил, что Bcachefs определённо более надёжна, чем Btrfs и он работает над тем, чтобы сделать её более устойчивой и надежной, чем XFS и EXT4, благодаря реализации механизма сквозной целостности данных (end to end data Integrity). Кент также подчеркнул, что предлагаемые изменения напрямую касаются повышения надёжности, и если ошибка в других подсистемах ядра возможно ограничится сбоем и перезагрузкой, то в файловых системах цена ошибки очень высока и может привести к скрытому повреждению данных, которое может быть замечено лишь недели спустя.

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

// cc-by opennet.ru
// converted with crypt’s opennet autoreposter <<<

  • Anonymous
    link
    fedilink
    arrow-up
    0
    ·
    2 years ago

    так чем она лучше того же ext4? снапшоты? больше нихуя.

    • tiinn
      link
      fedilink
      arrow-up
      0
      ·
      2 years ago

      Мотивацию к созданию ещё одной файловой системы Кент извлекает из текущей плачевной ситуации с файловыми системами в Linux:

      ext4: Да, она работает, но годы долгой эволюции берут своё. Серьёзные проблемы с качеством исходного кода, проблемы с производительностью, периодически выявляемые ошибки, приводящие к повреждению или потере хранимых данных. По мнению разработчиков ФС, надёжная работа этой ФС — это мираж, т.к. лучший компонент этой ФС — это fsck.

      XFS: Работает надёжно, качество и строгость исходного кода ФС является примером для подражания для всех остальных. XFS имеет классическую архитектуру: update-in-place, а не copy-on-write. Поэтому множество продвинутых функций в рамках этой ФС реализовать проблематично или просто невозможно.

      btrfs: ФС разрабатывалась под Linux как ФС следующего поколения, «наш ответ ZFS». Но она разрабатывалась на скорость, без проработки архитектуры. Например, допущено множество ошибок в формате хранимых данных, ужасное качество исходного кода и его огромный объем. Много людей уже погорело на btrfs.

      ZFS: Эта ФС показывает людям то, что они могут получать от copy-on-write ФС, но ФС живёт и развивается вне Linux, и на Linux она не ориентирована. Из технических особенностей: в отличие от остальных современных ФС, ZFS имеет block-based архитектуру вместо extent-based (сделано для упрощения реализации снимков на уровне ФС).

      Как видно, ситуация с файловыми системами в Linux оставляет желать лучшего, что же предлагает Kent? bcachefs уже сегодня — это:

      copy-on-write POSIX-совместимая ФС. Нижний слой ФС реализован на базе стабильного и оттестированного годами проекта bcache. Файловая система (при текущем наборе функций) уже стабильна и протестирована на хранении 50 ТБ+ данных. С момента первого анонса было выявлено лишь несколько мелких ошибок. Создатель ФС использует bcachefs на своём ноутбуке в качестве корневой.

      Высокая скорость работы. Со времени апрельских тестов производительности были сделаны оптимизации. В bcachefs хорошо отработан tail latency, практически отсутствуют блокировки потоков на вводе-выводе.

      Простой и понятный исходный код. Текущий исходный код меньше по объёму, чем ext4, но уже содержит большинство функций btrfs.

      • Oberstserj
        link
        fedilink
        arrow-up
        0
        ·
        2 years ago

        много красивой патетики

        Ладно-ладно, убедил, посмотрю.