Re: [RFC PATCH v2] xfs: support shrinking unused space in the last AG

[Brian Foster <bfoster@redhat.com>]

On Fri, Oct 30, 2020 at 11:02:59PM +0800, Gao Xiang wrote:
> Hi Brian,
> 
> On Fri, Oct 30, 2020 at 10:47:40AM -0400, Brian Foster wrote:
> > On Thu, Oct 29, 2020 at 07:13:53AM +0800, Gao Xiang wrote:
> 
> ...
> 
> > >  out_trans_cancel:
> > > +	if (extend && (tp->t_flags & XFS_TRANS_DIRTY)) {
> > > +		xfs_trans_commit(tp);
> > > +		return error;
> > > +	}
> > 
> > Do you mean this to be if (!extend && ...)?
> 
> Yeah, you are right.
> 
> > 
> > Otherwise on a quick read through this seems mostly sane to me. Before
> > getting into the implementation details, my comments are mostly around
> > patch organization and general development approach. On the former, I
> > think this patch could be split up into multiple smaller patches to
> > separate refactoring, logic cleanups, and new functionality. E.g.,
> > factoring out the existing growfs code into a helper, tweaking existing
> > logic to prepare the shared grow/shrink path, adding the shrinkfs
> > functionality, could all be independent patches. We probably want to
> > pull the other patch you sent for the experimental warning into the same
> > series as well.
> 
> ok.
> 
> > 
> > On development approach, I'm a little curious what folks think about
> > including these opportunistic shrink bits in the kernel and evolving
> > this into a more complete feature over time. Personally, I think that's
> > a reasonable approach since shrink has sort of been a feature that's
> > been stuck at the starting line due to being something that would be
> > nice to have for some folks but too complex/involved to fully implement,
> > all at once at least. Perhaps if we start making incremental and/or
> > opportunistic progress, we might find a happy medium where common/simple
> > use cases work well enough for users who want it, without having to
> > support arbitrary shrink sizes, moving the log, etc.
> 
> My personal thought is also incremental approach. since I'm currently
> looking at shrinking a whole unused AG, but such whole modification
> is all over the codebase, so the whole shrink function would be better
> to be built step by step.
> 
> > 
> > That said, this is still quite incomplete in that we can only reduce the
> > size of the tail AG, and if any of that space is in use, we don't
> > currently do anything to try and rectify that. Given that, I'd be a
> > little hesitant to expose this feature as is to production users. IMO,
> > the current kernel feature state could be mergeable but should probably
> > also be buried under XFS_DEBUG until things are more polished. To me,
> > the ideal level of completeness to expose something in production
> > kernels might be something that can 1. relocate used blocks out of the
> > target range and then possibly 2. figure out how to chop off entire AGs.
> > My thinking is that if we never get to that point for whatever
> > reason(s), at least DEBUG mode allows us the flexibility to drop the
> > thing entirely without breaking real users.
> 
> Yeah, I also think XFS_DEBUG or another experimential build config
> is needed.
> 
> Considering that, I think it would better to seperate into 2 functions
> as Darrick suggested in the next version to avoid too many
> #ifdef XFS_DEBUG #endif hunks.
> 

Another option could be to just retain the existing error checking logic
and wrap it in an ifdef. I.e.:

#ifndef DEBUG
	/* shrink only allowed in debug mode for now ... */
	if (nb < mp->m_sb.sb_dblocks)
		return -EINVAL;
#endif

Then the rest of the function doesn't have to be factored differently
just because of the ifdef.

Brian

> Thanks,
> Gao Xiang
> 
> > 
> > Anyways, just some high level thoughts on my part. I'm curious if others
> > have thoughts on that topic, particularly since this might be a decent
> > point to decide whether to put effort into polishing this up or to
> > continue with the RFC work and try to prove out more functionality...
> > 
> > Brian
> > 
> > >  	xfs_trans_cancel(tp);
> > >  	return error;
> > >  }
> > > diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
> > > index c94e71f741b6..81b9c32f9bef 100644
> > > --- a/fs/xfs/xfs_trans.c
> > > +++ b/fs/xfs/xfs_trans.c
> > > @@ -419,7 +419,6 @@ xfs_trans_mod_sb(
> > >  		tp->t_res_frextents_delta += delta;
> > >  		break;
> > >  	case XFS_TRANS_SB_DBLOCKS:
> > > -		ASSERT(delta > 0);
> > >  		tp->t_dblocks_delta += delta;
> > >  		break;
> > >  	case XFS_TRANS_SB_AGCOUNT:
> > > -- 
> > > 2.18.1
> > > 
> > 
>