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..
> > 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.
