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