On Tue, Sep 05, 2023 at 08:00:07PM -0400, Kent Overstreet wrote: > On Tue, Sep 05, 2023 at 06:24:47AM -0700, Christoph Hellwig wrote: > > Hi Kent, > > > > I thought you'd follow Christians proposal to actually work with > > people to try to use common APIs (i.e. to use iomap once it's been > > even more iter-like, for which I'm still waiting for suggestions), > > and make your new APIs used more widely if they are a good idea > > (which also requires explaining them better) and aim for 6.7 once > > that is done. > > Christoph, I get that iomap is your pet project and you want to make it > better and see it more widely used. > > But the reasons bcachefs doesn't use iomap have been discussed at > length, and I've posted and talked about the bcachefs equivalents of > 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. > > To recap, besides being more iterator like (passing data structures > around with iterators, vs. indirect function calls into the filesystem), > 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 /thought/ the proposal was to use iomap for bcachefs DIO and leave buffered writes for a different day. I agree the iomap buffered write path is inappropriate for bcachefs today. I'd like that to change, but there's a lot of functionality that it would need to support. I don't see the point in keeping bcachefs out of tree for another cycle. Yes, more use of iomap would be great, but I don't think that it being in-tree is going to hinder anything. It's not like it uses bufferheads.
