Bcachefs File-System Re-Submitted For Linux 6.6

[Quackdoc]

Why shouldn't it though? It won't affect those not using it, and it's marked as experimental, and there's nothing special about the state of the kernel when one is declared to have LTS support, barring no particularly problematic issues. Also other file systems were added in LTS releases before.

Even if it is experimental, LTS to me has always presented extra maitnence burden, I suppose being marked experimental can alleviate that burden though. wont stop users however

[timofonic]

There's some iomap related discussion, but some others want this to be merged NOW. There's some hope.

I /thought/ the proposal was to use iomap for bcachefs DIO and leave buffered writes for a different day. I agree the iomap buffered write path is inappropriate for bcachefs today. I'd like that to change, but there's a lot of functionality that it would need to support.

I don't see the point in keeping bcachefs out of tree for another cycle.
Yes, more use of iomap would be great, but I don't think that it being in-tree is going to hinder anything. It's not like it uses bufferheads.

I hope Michael massages LKML discussions to something understandable for us mere mortals in a news article

[fitzie]

Why shouldn't it though? It won't affect those not using it, and it's marked as experimental, and there's nothing special about the state of the kernel when one is declared to have LTS support, barring no particularly problematic issues. Also other file systems were added in LTS releases before.

The rules of -stable seem to preclude bcachefs introduction. From: https://www.kernel.org/doc/html/late...nel-rules.html

Rules on what kind of patches are accepted, and which ones are not, into the "-stable" tree:

• It must be obviously correct and tested.
• It cannot be bigger than 100 lines, with context.
• It must fix only one thing.
• It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
• It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
• Serious issues as reported by a user of a distribution kernel may also be considered if they fix a notable performance or interactivity issue. As these fixes are not as obvious and have a higher risk of a subtle regression they should only be submitted by a distribution kernel maintainer and include an addendum linking to a bugzilla entry if it exists and additional information on the user-visible impact.
• New device IDs and quirks are also accepted.
• No "theoretical race condition" issues, unless an explanation of how the race can be exploited is also provided.
• It cannot contain any "trivial" fixes in it (spelling changes, whitespace cleanups, etc).
• It must follow the Documentation/process/submitting-patches.rst rules.
• It or an equivalent fix must already exist in Linus' tree (upstream).

[stiiixy]

or, how many non native English speakers will say, BitchFS

I was actually thinking along the lines of Group X Arabian Rap Sensations-styled 'BacheFS'.

With FS being 'fucks sake' if you know Group X.

[Old Grouch]

I must admit, I'm not familiar with the path for including major chunks of new code into the Linux kernel, but reading what Linus is reported to have written makes me understand that the correct path is via inclusion in linux-next, and Kent Overstreet has not done this. Assuming the process is well-known (or at least, sufficiently documented), I'm disappointed that this has not been done.

I'm cautiously optimistic that bcachefs will, eventually be incorporated into the kernel, but it might be a while. From what I've read, it looks like inclusion in 6.6, or even 6.7 could well be unlikely, if the linux-next requirement is to be fulfilled.

Usually, having a strictly enforced process that everybody has to follow helps to get personality issues out of the way. It's when favours are done, or process steps become optional for unspecified reasons that things get difficult.

I hope that we don't lose any maintainers over this, or that Kent gives up. Neither would be a good outcome, and nor is adding extra burden on Linus' shoulders.

[andrei_me]

Are people really so simpleminded that they can only invent names based on the underlying technologies and then dropping a few letter along the way?

Flatpak, I don't remember the previous name while it was being developed, something like xdg-app, anyway, when it was time to release as v1.0 they gave it a better name