Re: [PATCH 8/9] xfs: support in-memory btrees

Darrick J. Wong
2024-01-04T07:33:32Z

On Wed, Jan 03, 2024 at 11:30:27PM -0800, Christoph Hellwig wrote:
> On Wed, Jan 03, 2024 at 11:27:52PM -0800, Darrick J. Wong wrote:
> > > Btw, one thing I noticed is that we have a lot of confusion on what
> > > part of the bc_ino/ag/mem union is used for a given btree. For
> > > On-disk inodes we abuse the long ptrs flag, and then we through in
> > > the xfile flags. If you're fine with it I can try to sort it out.
> > > It's not really a blocker, but I think it would be a lot claner if
> > > we used the chance to sort it out. This will become even more
> > > important with the rt rmap/reflink trees that will further increase
> > > the confusion here.
> >
> > Go for it! :)
>
> Happy to do it you don't complain about all the rebase pain it'll
> cause..

You might want to wait a bit for my XFS_BTREE_ -> XFS_BTGEO_ change to
finish testing so I can repost. That alone will cause a fair amount of
rebasing.

> > > That means xfs_btree.c can use the target from it, and the owner
> > > and we can remove the indirect calls for calculcating maxrecs/minrecs,
> > > and then also add a field for the block size like this one and remove
> > > a lof of the XFS_BTREE_IN_XFILE checks.
> >
> > Sounds like a good idea.
>
> Same here.
>
> >
> > > > + if (cur->bc_flags & XFS_BTREE_IN_XFILE)
> > > > + return 0;
> > > > +
> > > > if ((lr & XFS_BTCUR_LEFTRA) && left != NULLFSBLOCK) {
> > > > xfs_btree_reada_bufl(cur->bc_mp, left, 1,
> > >
> > > Should the xfile check go into xfs_buf_readahead instead? That would
> > > execute a little more useles code for in-memory btrees, but keep this
> > > check in one place (where we could also write a nice comment explaining
> > > it :))
> >
> > Sure, why not? It's too bad that readahead to an xfile can't
> > asynchronously call xfile_get_page; maybe we wouldn't need so much
> > caching.
>
> Actualy page lookup or allocation never is async, so this would only
> be about reading swap from disk. And given what a mess the swap code
> is I don't think we'll have an async read for that any time soon.

Yeah, I was afraid you were gonna say that. :(

--D