Yeah, of course there were the disk accounting issues and before that was the kernel upgrade-downgrade bug going from 6.8 back to 6.7. Currently over on Reddit at least one user is mention read errors and / or performance regressions on the current RC version that I'd rather avoid. There were a number of other issues that cropped up in some earlier versions but not others such as deadlocks when using compression (particularly zstd), weirdness when using compression with 4k blocks and suspend / resume failures when using bcachefs. None of those things were a big deal to me as I mostly only use bcachefs on root filesystems which are of course easy to recreate. But I do currently use bcachefs for all the filesystems on my main laptop so issues there can be more of a pain. As an example of potential issues I'd like to avoid I often upgrade my laptop and swap the old SSD in and am currently considering pulling the trigger on a Ryzen AI laptop such as the ProArt P16. However, this new processor has some cutting edge features only fully supported in 6.12 so I'd prefer to use that kernel if I can. But... because according to Reddit there are apparently issues with bcachefs in the 6.12RC kernels that means I am hesitant to buy the laptop and use the RC kernel the carefree manor I normally would. Yeah, first world problems! Speaking of Reddit, I don't know if you saw it but a user there quotes you as saying users who use release candidates should expect them to be "dangerous as crap." I could not find a post where you said that in the thread that user pointed to but if you **did** say something like that then I guess I have a different concept of what "release candidate" means. So for me it would be a lot easier if bcachefs versions were decoupled from kernel versions. Thanks, Carl > On 2024-10-05 6:56 PM PDT Kent Overstreet <kent.overstreet@xxxxxxxxx> wrote: > > > 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.
