Re: [GIT PULL] bcachefs fixes for 6.12-rc2

[Kent Overstreet]

On Sat, Oct 05, 2024 at 06:20:53PM GMT, Carl E. Thompson wrote:
> Here is a user's perspective from someone who's built a career from Linux (thanks to all of you)...
> 
> The big hardship with testing bcachefs before it was merged into the kernel was that it couldn't be built as an out-of-tree module and instead a whole other kernel tree needed to be built. That was a pain.
> 
> Now, the core kernel infrastructure changes that bcachefs relies on are in the kernel and bcachefs can very easily and quickly be built as an out-of-tree module in just a few seconds. I submit to all involved that maybe that's the best way to go **for now**. 
> 
> Switching to out of tree for now would make it much easier for Kent to have the fast-paced development model he desires for this stage in bcachefs' development. It would also make using and testing bcachefs much easier for power users like me because when an issue is detected we could get a fix or new feature much faster than having to wait for a distribution to ship the next kernel version and with less ancillary risk than building and using a less-tested kernel tree. Distributions themselves also are very familiar with packaging up out-of-tree modules and distribution tools like dkms make using them dead simple even for casual users.
> 
> The way things are now isn't great for me as a Linux power user. I
> often want to use the latest or even RC kernels on my systems to get
> some new hardware support or other feature and I'm used to being able
> to do that without too many problems. But recently I've had to skip
> cutting-edge kernel versions that I otherwise wanted to try because
> there have been issues in bcachefs that I didn't want to have to face
> or work around. Switching to an out of tree module for now would be
> the best of all worlds for me because I could pick and choose which
> combination of kernel / bcachefs to use for each system and situation.

Carl - thanks, I wasn't aware of this.

Can you give me details? 6.11 had the disk accounting rewrite, which was
huge and (necessarily) had some fallout, if you're seeing regressions
otherwise that are slipping through then - yes it's time to slow down
and reevaluate.

Details would be extremely helpful, so we can improve our regression
testing.