Re: [GIT PULL] bcachefs

[Darrick J. Wong]

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