On Thu, Nov 21, 2024 at 03:17:04PM +0800, Stephen Zhang wrote: > Dave Chinner <david@xxxxxxxxxxxxx> 于2024年11月21日周四 06:53写道： > > > > On Sun, Nov 17, 2024 at 09:34:53AM +0800, Stephen Zhang wrote: > > > Dave Chinner <david@xxxxxxxxxxxxx> 于2024年11月11日周一 10:04写道： > > > > > > > > On Fri, Nov 08, 2024 at 09:34:17AM +0800, Stephen Zhang wrote: > > > > > Dave Chinner <david@xxxxxxxxxxxxx> 于2024年11月4日周一 20:15写道： > > > > > > On Mon, Nov 04, 2024 at 05:25:38PM +0800, Stephen Zhang wrote: > > > > > > > Dave Chinner <david@xxxxxxxxxxxxx> 于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@xxxxxxxxxxxxx
