Re: [GIT PULL] bcachefs

From: Christoph Hellwig <hch@infradead.org>
To: Kent Overstreet <kent.overstreet@linux.dev>
Cc: Christoph Hellwig <hch@infradead.org>,
	torvalds@linux-foundation.org, linux-kernel@vger.kernel.org,
	linux-fsdevel@vger.kernel.org, linux-bcachefs@vger.kernel.org,
	Christian Brauner <christian@brauner.io>
Subject: Re: [GIT PULL] bcachefs
Date: Fri, 8 Sep 2023 02:37:54 -0700	[thread overview]
Message-ID: <ZPrrcpZgJWFfFfEL@infradead.org> (raw)
In-Reply-To: <20230906000007.ry5rmk35vt57kppx@moria.home.lan>

On Tue, Sep 05, 2023 at 08:00:07PM -0400, Kent Overstreet wrote:
> But the reasons bcachefs doesn't use iomap have been discussed at
> length,

Care to send a pointer?

> that code. You were AWOL on those discussions; you consistently say
> "bcachefs should use iomap" and then walk away, so those discussions
> haven't moved forwards.

Well, let's hsave the proper discussion then.  I defintively don't
think "I just walked away", because that's not what I do.  I did give
up on quite a few of discussions with your because they turned from
technical into personal very quick, but I don't even remember that
for this case.

> To recap, besides being more iterator like (passing data structures
> around with iterators,

Which is something you can do with iomap, and we're making use of that
in quite a few places.  Thanks to the work from willy that I helped a
bit with this has been done years ago.  It might or might not make
sense to replace iomap_begin/end with a single iter callback that
can be inlined, but that's not changing anything fundamental.

> bcachefs also hangs a bit more state off the pagecache, due to being
> multi device and also using the same data structure for tracking disk
> reservations (because why make the buffered write paths look that up
> separately?).

I'm not even parsing the sentence.  But as said many times I'm all ear
if we stick to technical questions.  We've added all kinds of
improvements to iomap especially for gfs2 and btrfs, and while it
sometimes took some time we're all better off with that as we're
converging on a model of doing I/O instead of everytone doing something
slightly different.

> 
> > But without that, and without being in linux-next and the VFS maintainer
> > ACK required for I think this is a very bad idea.
> 
> Christain gave his reviewed-by for the dcache patch. Since this patchset
> doesn't change existing code maintained by others aside from that one
> patch, not sure how linux-next is relevant here...

Because file systems really should have a VFS maintainer ACK, just like
block drivers have a block maintainer ACK, or network drivers have a
net maintainer ACK.  Doing this differently for the most complex driver
interface in the kernel doesn't make any sense whatsover. 