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