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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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




[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux