On Wed, Sep 06, 2023 at 05:03:06PM -0700, Kees Cook wrote: > On Wed, Sep 06, 2023 at 03:28:47PM -0700, Nathan Chancellor wrote: > > Hi Kent, > > > > On Sat, Sep 02, 2023 at 11:25:55PM -0400, Kent Overstreet wrote: > > > here's the bcachefs pull request, for 6.6. Hopefully everything > > > outstanding from the previous PR thread has been resolved; the block > > > layer prereqs are in now via Jens's tree and the dcache helper has a > > > reviewed-by from Christain. > > > > I pulled this into mainline locally and did an LLVM build, which found > > an immediate issue. It appears the bcachefs codes uses zero length > > It looks like this series hasn't been in -next at all? That seems like a > pretty important step. > > Also, when I look at the PR, it seems to be a branch history going > back _years_. For this kind of a feature, I'd expect a short series of > "here's the code" in incremental additions (e.g. look at the x86 shstk > series), not the development history from it being out of tree -- this > could easily lead to ugly bisection problems, etc. I disagree entirely. One of the most valuable things we have for XFS is a complete change history going back to the first commit in 1993. We don't have all that in the kernel git tree - that only goes back to 2005. We do, however, have a separate git archive that runs from the initial commit in 1993 to 2008, and so we can track bugs and changes back all the way to when they were first introduced. I'm looking at something in that historic XFS archive every second day; understanding the XFS code and why it is like it is requires looking back in time on a regular basis. And because XFS engineers have been really good with commit messages for a really long time, there is a lot of information in that historic archive that is simply not documented anywhere else. So if we have the full history of bcachefs developement sitting in a git tree, we'd be *utterly stupid* to discard it when merging it into the mainline tree. Nothing else documents the reasons for the code being like it is right now better than the change history of the code. For people trying to understand the code or trying to perform root cause analysis of a bug, a complete revision history is a rich gold mine full of valuable nuggets.... -Dave. -- Dave Chinner david@xxxxxxxxxxxxx
