On Tue, Jul 11, 2023 at 10:54:59PM -0400, Kent Overstreet wrote: > So: looks like we missed the merge window. Boo :) > > Summing up discussions from today's cabal meeting, other off list > discussions, and this thread: > > - bcachefs is now marked EXPERIMENTAL > > - Brian Foster will be listed as a reviewer /me applauds! > - Josef's stepping up to do some code review, focusing on vfs-interacty > bits. I'm hoping to do at least some of this in a format where Josef > peppers me with questions and we turn that into new code > documentation, so others can directly benefit: if anyone has an area > they work on and would like to see documented in bcachefs, we'll take > a look at that too. > > - Prereq patch series has been pruned down a bit more; also Mike > Snitzer suggested putting those patches in their own branch: > > https://evilpiepirate.org/git/bcachefs.git/log/?h=bcachefs-prereqs > > "iov_iter: copy_folio_from_iter_atomic()" was dropped and replaced > with willy's "iov_iter: Handle compound highmem pages in > copy_page_from_iter_atomic()"; he said he'd try to send this for -rc4 > since it's technically a bug fix; in the meantime, it'll be getting > more testing from my users. > > The two lockdep patches have been dropped for now; the > bcachefs-for-upstream branch is switched back to > lockdep_set_novalidate_class() for btree node locks. > > six locks, mean and variance have been moved into fs/bcachefs/ for > now; this means there's a new prereq patch to export > osq_(lock|unlock) > > The remaining prereq patches are pretty trivial, with the exception > of "block: Don't block on s_umount from __invalidate_super()". I > would like to get a reviewed-by for that patch, and it wouldn't hurt > for others. > > previously posting: > https://lore.kernel.org/linux-bcachefs/20230509165657.1735798-1-kent.overstreet@xxxxxxxxx/T/#m34397a4d39f5988cc0b635e29f70a6170927746f > > - Code review was talked about a bit earlier in the thread: for the > moment I'm just posting big stuff, but I'd like to aim for making > sure all patches (including mine) hit the linux-bcachefs mailing list > in the future: > > https://lore.kernel.org/linux-bcachefs/20230709171551.2349961-1-kent.overstreet@xxxxxxxxx/T/ > > - We also talked quite a bit about the QA process. I'm going to work on > finally publishing ktest/ktestci, which is my test infrastructure > that myself and a few other people are using - I'd like to see it > used more widely. > > For now, here's the test dashboard for the bcachefs-for-upstream > branch: > https://evilpiepirate.org/~testdashboard/ci?branch=bcachefs-for-upstream > > - Also: not directly related to upstreaming, but relevant for the > community: we talked about getting together a meeting with some of > the btrfs people to gather design input, ideas, and lessons learned. Please invite me too! :) Granted XFS doesn't do multi-device support (for large values of 'multi') but now that I've spent 6 years of my life concentrating on repairability for XFS, I might have a few things to say about bcachefs. That is if I can shake off the torrent of syzbot crap long enough to read anything in bcachefs.git. :( --D > If anyone would be interested in working on and improving the multi > device capabilities of bcachefs in particular, this would be a great > time to get involved. That stuff is in good shape and seeing a lot of > active use - it's one of bcachefs's major drawing points - and I want > it to be even better. > > And here's the branch I intend to re-submit next merge window, as it > currently sits: > https://evilpiepirate.org/git/bcachefs.git/log/?h=bcachefs-for-upstream > > Please chime in if I forgot anything important... :) > > Cheers, > Kent
