Re: [PATCH 10/13] xfs: re-order AGI updates in unlink list updates

Dave Chinner
2020-08-19T01:01:35Z

On Tue, Aug 18, 2020 at 05:29:48PM -0700, Darrick J. Wong wrote:
> On Wed, Aug 12, 2020 at 07:25:53PM +1000, Dave Chinner wrote:
> > From: Dave Chinner <dchinner@redhat.com>
> >
> > We always access and check the AGI bucket entry for the unlinked
> > list even if we are not going to need it either for lookup or remove
> > purposes. Move the code that accesses the AGI to the code that
> > modifes the AGI, hence keeping the AGI accesses local to the code
> > that needs to modify it.
> >
> > Signed-off-by: Dave Chinner <dchinner@redhat.com>
> > ---
> > fs/xfs/xfs_inode.c | 84 ++++++++++++++++------------------------------
> > 1 file changed, 28 insertions(+), 56 deletions(-)
> >
> > diff --git a/fs/xfs/xfs_inode.c b/fs/xfs/xfs_inode.c
> > index b098e5df07e7..4f616e1b64dc 100644
> > --- a/fs/xfs/xfs_inode.c
> > +++ b/fs/xfs/xfs_inode.c
> > @@ -1918,44 +1918,53 @@ xfs_inactive(
> > */
> >
> > /*
> > - * Point the AGI unlinked bucket at an inode and log the results. The caller
> > - * is responsible for validating the old value.
> > + * Point the AGI unlinked bucket at an inode and log the results. The caller
> > + * passes in the expected current agino the bucket points at via @cur_agino so
> > + * we can validate that we are about to remove the inode we expect to be
> > + * removing from the AGI bucket.
> > */
> > -STATIC int
> > +static int
> > xfs_iunlink_update_bucket(
> > struct xfs_trans *tp,
> > xfs_agnumber_t agno,
> > struct xfs_buf *agibp,
> > - xfs_agino_t old_agino,
> > + xfs_agino_t cur_agino,
>
> Hm. So I think I understand the new role of this function better now
> that this patch moves into this function the checking of the bucket
> pointer and whatnot. Would it be difficult to merge this patch with
> patch 4?

I really didn't want to remove the code that used the "head_agino"
for verification until I had moved all the list traversal
functionality to use the in memory unlinked list and had verified
that was correct....

I think merging them it could be done, but it will most likely
result in having to rebase and retest every subsequent patch...

Cheers,

Dave.
--
Dave Chinner
david@fromorbit.com