Re: [GIT PULL] bcachefs

Darrick J. Wong
2023-07-12T22:10:19Z

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@linux.dev/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@linux.dev/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