{"id":138411,"date":"2025-06-28T11:12:07","date_gmt":"2025-06-28T09:12:07","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17"},"modified":"2025-06-28T11:12:07","modified_gmt":"2025-06-28T09:12:07","slug":"linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17","status":"publish","type":"post","link":"https:\/\/prohoster.info\/en\/blog\/news\/linus-tovalds-nameren-isklyuchit-bcachefs-iz-yadra-linux-6-17","title":{"rendered":"Linus Torvalds intends to exclude Bcachefs from the Linux 6.17 kernel","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Another discussion between Linus Torvalds and Kent Overstreet, the author of Bcachefs, concluded with Linus expressing his willingness to exclude Bcachefs code from the Linux 6.17 kernel. At the same time, Linus accepted changes to Bcachefs in kernel 6.16, which had become a source of Kent's ongoing dissatisfaction. Linus wrote: <\/p>\n
\n
I believe our paths will diverge in the 6.17 merge window. <\/p>\n
You made it very clear that I cannot question any bug fixes and must just accept everything. <\/p>\n
To be honest, I don't feel particularly comfortable being involved in all of this, and the only thing we both seem to really agree on in the discussion is that 'we're done'. <\/p><\/blockquote>\n
The correspondence leading up to this statement with Kent was conducted privately, and the details are still unclear. However, in discussing this topic, Kent wrote that it is possible his words in the private correspondence were misinterpreted, and he does not believe that BcacheFS should be excluded from the kernel. At the same time, he is open to stopping the inclusion of Bcachefs in the main Linux kernel, which would not kill the project, although it would be a huge problem. If Bcachefs is removed, development will continue, and this filesystem will be distributed as a DKMS module. Kent also noted that excluding BcacheFS from the kernel would be the best option for his peace with Linus, but it clearly would not be the best solution for users and the developer community. <\/p>\n
The disputes between Kent and Linus are caused by constant violations of the rules for submitting changes and fixes to the kernel. Kent believes that fixes for issues in the filesystem should be pushed forward promptly and by any means necessary. Linus insists that functional changes and significant fixes are permissible only in the early stages of developing a new kernel branch, while late-stage release candidates focus solely on bug fixes. Kent regularly violates this rule, sending large changes at inappropriate times, leading to Linus's dissatisfaction and a new wave of disputes. Linus had previously warned Kent about the desire to remove Bcachefs from the main kernel, as Kent continues to play alone in his sandbox, not engaging in collaborative work and refusing to adhere to the community of kernel developers' rules. <\/p>\n
In the case of kernel 6.16, Kent sent a set of patches for inclusion in the RC3 update, among which was a patch implementing the new 'journal_rewind' option. Linus wrote that Kent forgot that after the cutoff for functional changes, adding new functionality to the kernel is not allowed, even if it is related to fixing other bugs, as introducing new features in the later stages of release development can lead to regressions. Furthermore, Bcachefs continues to be positioned as an experimental filesystem, and the promptness of bug fixes in it is not considered crucial. <\/p>\n
Kent responded that the main goal of development is to provide users with working code, so he is not willing to compromise on issues affecting data integrity. Unlike other subsystems, bugs in the filesystem cannot be resolved by rebooting and can lead to data corruption; therefore, in Kent's view, delaying their resolution until the next window for changes is unacceptable, even if such fixes require significant changes. <\/p>\n
The added 'journal_rewind' option rolled back changes in the journal to reset the filesystem to an earlier state. Kent believes that this new option should be implemented immediately, as it addresses the issue of filesystem recovery for users who encountered a bug when deleting subvolumes and do not have a backup. Initially, Linus refused to accept the patch set with this change into kernel 6.16-RC3, but after personal correspondence with Kent, he changed his position and accepted the changes into the codebase that forms the 6.16-RC4 update. \n Source: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"