В основную ветку Linux перед выпуском 7.2-rc7 вернули механизм Btrfs fixup worker, удалённый в начале цикла 7.2. Разработчики выяснили, что без него отдельные изменённые области памяти могли пройти мимо штатной подготовки Copy-on-Write и привести к тихой потере данных — ситуации, когда ошибка не обязательно сообщает о себе пользователю.
Btrfs возвращает механизм, удалённый в начале цикла Linux 7.2
История получилась редкой для поздней стадии разработки ядра. Во время окна слияния Linux 7.2 из Btrfs убрали инфраструктуру fixup worker: разработчики исходили из того, что изменения в подсистеме управления памятью уже закрыли сценарии, для которых этот механизм когда-то понадобился. К августу выяснилось, что предположение оказалось слишком оптимистичным.
6 августа сопровождающий Btrfs Дэвид Стерба отправил отдельный pull request с возвратом fixup worker. По его описанию, механизм нужен для обнаружения страниц и folio, которые получили признак изменённых без участия файловой системы и поэтому требуют дополнительной подготовки COW. Стерба сформулировал последствие предельно прямо: в переводе его слов, отсутствие такой обработки может привести к «тихой потере данных».
Изменение уже принял Линус Торвальдс, и восстановленный код находится в основной ветке Linux. При этом сам Linux 7.2-rc7 на момент проверки 7 августа ещё не опубликован: kernel.org показывает Linux 7.2-rc6 от 2 августа как текущую mainline-версию. Поэтому речь идёт о коде, подготовленном для следующего кандидата, а не о состоявшемся выпуске rc7.
Fixup worker ловит изменённые folio, прошедшие мимо обычного COW-пути
Чтобы понять серьёзность исправления, достаточно разобрать один термин. Btrfs использует Copy-on-Write, или COW: при изменении данных файловая система обычно записывает новую версию блока в другое место, а затем обновляет ссылки на него. Такой порядок помогает сохранять согласованность метаданных и лежит в основе снимков Btrfs.
Есть и второй участник этой схемы — кэш страниц в памяти. Современное ядро Linux оперирует объектами folio, которые могут объединять одну или несколько физических страниц памяти. Если данные в таком объекте изменились, он получает признак dirty, то есть должен быть записан на накопитель.
В коде Btrfs существуют пути, где верхние уровни ядра способны пометить страницу или folio как dirty напрямую. Комментарии в исходном коде ядра прямо объясняют проблему: файловой системе требуется убедиться, что COW подготовлен корректно и соблюдены правила режима data=ordered. Fixup worker как раз подхватывает такой объект, резервирует необходимое пространство и переводит запись в состояние, которое Btrfs умеет безопасно обработать.
После удаления этого механизма в Linux 7.2 часть таких сценариев осталась без страховочной обработки. В результате изменённые данные могли дойти до writeback — фоновой записи содержимого из памяти на накопитель — без ожидаемой для Btrfs подготовки.
Тихая потеря данных опасна отсутствием явного сигнала об ошибке
Обычный сбой ввода-вывода заметен: приложение получает ошибку, файловая система пишет сообщение в журнал, операция завершается с ненулевым кодом. Тихая потеря данных устроена хуже: запись может внешне пройти штатно, а фактическое содержимое файла впоследствии оказывается неполным или отличается от того, что ожидала программа.
Именно этот класс риска стал причиной возврата механизма на поздней стадии цикла Linux 7.2. В pull request Дэвида Стербы описывается ситуация, когда dirty-страницы или folio появляются без знания файловой системы и требуют COW fixup. Вторичный разбор Phoronix от 6 августа подтверждает, что изменение уже вошло в Linux Git.
Для систем, использующих Btrfs, практический смысл связан именно с целостностью записываемых файлов. Сервер может продолжать работать, приложение может завершить запись без заметного аварийного сообщения, а проблема обнаружится уже при повторном чтении данных. Такая модель отказа особенно неприятна для файловой системы, которая часто используется ради снимков, контрольных сумм и других механизмов сохранности данных.
Возврат более 600 строк на стадии rc показывает масштаб исправления
Поздние кандидаты ядра обычно получают сравнительно небольшие и локальные исправления: чем ближе финальный релиз, тем осторожнее разработчики относятся к крупным изменениям. В данном случае в дерево возвращается более 600 строк кода инфраструктуры fixup worker.
Размер объясняется тем, что восстановление включает сам рабочий механизм, вспомогательный код и отладочную часть. По словам Стербы, примерно половина изменения приходится на debugging и support code, остальная часть относится к обнаружению проблемного состояния и его исправлению. Код одновременно адаптирован к современной folio API и поддержке размера блока меньше страницы, которые появились после первоначальной реализации механизма.
Такой объём для rc-стадии создаёт дополнительную интригу вокруг Linux 7.2. Разработчики фактически выбрали крупное исправление перед финальным выпуском, поскольку выявленный сценарий связан с сохранностью пользовательских данных.
В тот же набор вошли ещё три точечных исправления Btrfs
6 августа в основную ветку отправили и отдельный набор более обычных Btrfs fixes. Он исправляет утечку в пути encoded ioctl write, отключает large folios на системах с highmem и блокирует конфигурацию, где размер блока превышает размер страницы при отсутствии поддержки Transparent Huge Pages.
Эти изменения помогают понять контекст текущей фазы разработки Linux 7.2. Основные функции версии уже сформированы, а сопровождающие подсистем закрывают найденные регрессии и пограничные сценарии перед финальным релизом.
Btrfs оказался одной из подсистем, где исправление потребовало возвращения ранее удалённой инфраструктуры. История с fixup worker показывает, как изменение в одном слое ядра — управлении памятью — может неожиданно повлиять на гарантии файловой системы несколькими уровнями ниже.
Linux 7.2-rc7 ещё ожидается, а исправление Btrfs уже находится в основной ветке
По состоянию на 7 августа официальный kernel.org публикует Linux 7.2-rc6 как последний release candidate. Phoronix ожидает появление rc7 в ближайшие выходные, однако официальной страницы релиза rc7 на момент подготовки материала нет.
При этом ключевой факт уже зафиксирован в коде: инфраструктура Btrfs fixup worker возвращена в mainline после выявленного риска тихой потери данных. Открытым остаётся вопрос, принесёт ли позднее изменение дополнительные корректировки до финального Linux 7.2 и окажутся ли похожие сценарии в других путях записи Btrfs.
