Очередная [ дискуссия ](
https://lore.kernel.org/lkml/CAHk-=wi2ae794_MyuW1XJAR64RDkDLUsRHvSemuWAkO6T45=YA@mail.gmail.com/ ) между Линусом Торвальсом и Кентом Оверстритом (Kent Overstreet), автором BcacheFS, завершилась тем, что Линус [ выразил ](
https://lore.kernel.org/all/CAHk-=wi+k8E4kWR8c-nREP0+EA4D+=rz5j0Hdk3N6cWgfE03-Q@mail.gmail.com/ ) готовность исключить код BcacheFS из ядра Linux 6.17. При этом Линус [ принял ](
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6f2a71a99ebd5dfaa7948a2e9c59eae94b741bd8 ) в состав ядра 6.16 изменения в BcacheFS, ставшие предметом очередного недовольства действиями Кента. Линус написал:
Я считаю, что наши пути разойдутся в окне слияния 6.17.
Вы очень ясно дали понять, что я не могу подвергать сомнению какие-либо исправления ошибок и должен просто принимать всё подряд.
Честно говоря, я не чувствую себя особо комфортно, будучи вовлечённым во всё это, и единственное, с чем мы оба, похоже, действительно согласились в обсуждении, это то, что «мы закончили».
Предшествовавшая данному заявлению переписка с Кентом велась в личном порядке и детали пока не ясны. Тем не менее, в обсуждении данной темы Кент [ написал ](
https://lore.kernel.org/all/gxpaa7u46vicn5npm4plvvdd3iuowzts4oljuw2djfqny3rqae@n6vi53u6sa43/ ) , что возможно его слова в частной переписке были неправильно истолкованы и он не считает, что BcacheFS следует исключить из ядра. При этом он готов к прекращению поставки BcacheFS в основном составе ядра Linux и это не убьёт проект, хотя и будет огромной проблемой. В случае удаления BcacheFS разработка будет продолжена и данная ФС станет распространяться в форме модуля DKMS. Кент также отметил, что исключение BcacheFS из ядра будет лучшим вариантом для его с Линусом спокойствия, но явно не станет лучшим решением для пользователей и сообщества разработчиков.
Споры между Кентом и Линусом вызваны постоянными нарушениями правил отправки изменений и исправлений в ядро. Кент считает, что исправления проблем в ФС должны продвигаться безотлагательно и любыми возможными способами. Линус настаивает на том, что функциональные изменения и крупные исправления допускаются на начальной стадии разработки новой ветки ядра, а поздние кандидаты в релизы сосредоточены только на исправлении ошибок. Кент регулярно нарушает данное правило и присылает крупные изменения в неподходящий момент, что приводит к недовольству Линуса и к новой волне споров. Ранее Линус уже предупреждал Кента о желании удалить BcacheFS из основного ядра, так как Кент продолжает играть один в своей песочнице, не подключается к совместной работе и не желает принимать правила игры сообщества разработчиков ядра.
В случае с ядром 6.16 Кент отправил для включения в обновление RC3 [ набор патчей ](
https://lore.kernel.org/lkml/4xkggoquxqprvphz2hwnir7nnuygeybf2xzpr5a4qtj4cko6fk@dlrov4usdlzm/ ) , среди которых был патч с реализацией новой опции «journal_rewind». Линус [ написал ](
https://lore.kernel.org/lkml/CAHk-=wi2ae794_MyuW1XJAR64RDkDLUsRHvSemuWAkO6T45=YA@mail.gmail.com/ ) , что Кент забыл о том, что после закрытия окна приёма функциональных изменений добавление новой функциональности в ядро не допускается, даже если она связана с исправлением других ошибок, так как добавление новых возможностей на поздних стадиях формирования релиза может привести к регрессиям. Кроме того, BcacheFS продолжает позиционироваться как экспериментальная ФС и оперативность устранения ошибок в ней не является столь критичной.
Кент [ ответил ](
https://lore.kernel.org/lkml/lyvczhllyn5ove3ibecnacu323yv4sm5snpiwrddw7tyjxo55z@6xea7oo5yqkn/ ) , что главная цель разработки - предоставить пользователям работающий код, поэтому он [ не намерен ](
https://lore.kernel.org/all/xl2fyyjk4kjcszcgypirhoyflxojzeyxkzoevvxsmo26mklq7i@jw2ou76lh2py/ ) уступать в вопросах, касающихся исправления ошибок, влияющих на сохранение целостности данных. В отличие от других подсистем, ошибки в ФС не решаются перезагрузкой и могут приводить к повреждению данных, поэтому, по мнению Кента, откладывание их исправления до следующего окна приёма изменений недопустимо, даже если подобные исправления требуют внесения крупных изменений.
Добавленная опция «journal_rewind» откатывала изменения в журнале для сброса ФС в более раннее состояние. Кент считает, что новая опция должна быть включена безотлагательно, так как она решает проблему с восстановлением ФС у пользователей, столкнувшихся с ошибкой при удалении подразделов и не имеющих резервной копии. Вначале Линус отказался принимать набор патчей с данным изменением в ядро 6.16-RC3, но после личной переписки с Кентом изменил свою позицию и принял изменения в кодовую базу, на основе которой формируется обновление 6.16-RC4.
https://www.linux.org.ru/news/kernel/18013060