On Wed, Jul 26, 2023 at 06:20:42AM -0700, Christoph Hellwig wrote: > On Mon, Jul 24, 2023 at 11:00:37PM -0400, Kent Overstreet wrote: > > In short, iomap is heavily callback based, the bcachefs io paths are > > not - we pass around data structures instead. I discussed this with > > people when iomap was first being written, but iomap ended up being a > > much more conservative approach, more in line with the old buffer heads > > code where the generic code calls into the filesystem to obtain > > mappings. > > > > I'm gradually convincing people of the merits of the bcachefs approach - > > in particular reducing indirect function calls is getting more attention > > these days. > > FYI, Matthew has had patches that convert iomap to be an iterator, > and I've massage the first half of them and actuall got them in > before. I'd much rather finish off that work (even if only for > direct I/O initially) than adding another direct I/O code. But > even with out that we should be able to easily pass more private > data, in fact btrfs makes pretty heavy use of that. That's wonderful, but getting iomap up to the level of what bcachefs needs is still going to be a pretty big project and it's not going to be my highest priority. bcachefs also hangs more state off of the pagecache, in bcachefs's equivvalent of iomap_page - we store reservations for dirty data there and a few other things, which means the buffered IO paths don't have to walk any other data structures. I think that's another idea you guys will want to steal, but a higher priority for me is getting a proper FUSE port done - and making bcachefs more tightly weddded to VFS library code is not likely to make that process any easier. Once a proper fuse port is done and we know what that looks like will be a better time for some consolidation.
