Message-ID: <Z0UbkWlaEuH9_bXd@dread.disaster.area>
Date: Tue, 26 Nov 2024 11:51:29 +1100
From: Dave Chinner <david@...morbit.com>
To: Stephen Zhang <starzhangzsd@...il.com>
Cc: djwong@...nel.org, dchinner@...hat.com, leo.lilong@...wei.com,
	wozizhi@...wei.com, osandov@...com, xiang@...nel.org,
	zhangjiachen.jaycee@...edance.com, linux-xfs@...r.kernel.org,
	linux-kernel@...r.kernel.org, zhangshida@...inos.cn
Subject: Re: [PATCH 0/5] *** Introduce new space allocation algorithm ***

On Thu, Nov 21, 2024 at 03:17:04PM +0800, Stephen Zhang wrote:
> Dave Chinner <david@...morbit.com> 于2024年11月21日周四 06:53写道：
> >
> > On Sun, Nov 17, 2024 at 09:34:53AM +0800, Stephen Zhang wrote:
> > > Dave Chinner <david@...morbit.com> 于2024年11月11日周一 10:04写道：
> > > >
> > > > On Fri, Nov 08, 2024 at 09:34:17AM +0800, Stephen Zhang wrote:
> > > > > Dave Chinner <david@...morbit.com> 于2024年11月4日周一 20:15写道：
> > > > > > On Mon, Nov 04, 2024 at 05:25:38PM +0800, Stephen Zhang wrote:
> > > > > > > Dave Chinner <david@...morbit.com> 于2024年11月4日周一 11:32写道：
> > > > > > > > On Mon, Nov 04, 2024 at 09:44:34AM +0800, zhangshida wrote:
> > > Hi, I have tested the inode32 mount option. To my suprise, the inode32
> > > or the metadata preferred structure (will be referred to as inode32 for the
> > > rest reply) doesn't implement the desired behavior as the AF rule[1] does:
> > >         Lower AFs/AGs will do anything they can for allocation before going
> > > to HIGHER/RESERVED AFs/AGS. [1]
> >
> > This isn't important or relevant to the experiment I asked you to
> > perform and report the results of.
> >
> > I asked you to observe and report the filesystem fill pattern in
> > your environment when metadata preferred AGs are enabled. It isn't
> > important whether inode32 exactly solves your problem, what I want
> > to know is whether the underlying mechanism has sufficient control
> > to provide a general solution that is always enabled.
> >
> > This is foundational engineering process: check your hypothesis work
> > as you expect before building more stuff on top of them. i.e.
> > perform experiments to confirm your ideas will work before doing
> > anything else.
> >
> > If you answer a request for an experiment to be run with "theory
> > tells me it won't work" then you haven't understood why you were
> > asked to run an experiment in the first place.
> >
> 
> If I understand your reply correctly, then maybe my expression is the

You didn't understand my reply correctly.

I asked you to stop repeating the same explanation of your algorithm
in response to every question I asked you.

I asked you to stop trying to explain why something you just
learnt about from a subject matter expert wouldn't fix your problem.

I asked you to perform an experiment to confirm behaviour was as
expected under your problematic workload.

Your reply:

> problem. What I replied before is:
> 1. I have tested the inode32 option with the metadata preferred AGs
> enabled(Yeah, I do check if the AG is set with
> XFS_AGSTATE_PREFERS_METADATA). And with the alternating-
> punching pattern, I observed that the preferred AG will still get fragmented
> quickly, but the AF will not.
> (That's what I meant in the first sentence of my previous reply...)

is simply restating what you said in the previous email that I
explicitly told you didn't answer the question I was asking you.

Please listen to what I'm asking you to do. You don't need to
explain anything to me, I just want you to run an experiment and
report the results.

This isn't a hard thing to do: the inode32 filesystem should fill to
roughly 50% before it really starts to spill to the lower AGs.
Record and paste the 'xfs_spaceman -c "freesp -a X"' histograms for
each AG when the filesystem is a little over half full.

That's it. I don't need you to explain anything to me, I simply want
to know if the inode32 allocation policy does, in fact, work the way
it is expected to under your problematic workload.

-Dave.
-- 
Dave Chinner
david@...morbit.com

Powered by blists - more mailing lists