Re: [PATCH v11 00/25] xfs: Delay Ready Attributes

[Allison Collins <allison.henderson@oracle.com>]

On 7/23/20 8:41 PM, Dave Chinner wrote:
> On Mon, Jul 20, 2020 at 05:15:41PM -0700, Allison Collins wrote:
>> Hi all,
>>
>> This set is a subset of a larger series for delayed attributes. Which is a
>> subset of an even larger series, parent pointers. Delayed attributes allow
>> attribute operations (set and remove) to be logged and committed in the same
>> way that other delayed operations do. This allows more complex operations (like
>> parent pointers) to be broken up into multiple smaller transactions. To do
>> this, the existing attr operations must be modified to operate as either a
>> delayed operation or a inline operation since older filesystems will not be
>> able to use the new log entries.  This means that they cannot roll, commit, or
>> finish transactions.  Instead, they return -EAGAIN to allow the calling
>> function to handle the transaction. In this series, we focus on only the clean
>> up and refactoring needed to accomplish this. We will introduce delayed attrs
>> and parent pointers in a later set.
>>
>> At the moment, I would like people to focus their review efforts on just this
>> "delay ready" subseries, as I think that is a more conservative use of peoples
>> review time.  I also think the set is a bit much to manage all at once, and we
>> need to get the infrastructure ironed out before we focus too much anything
>> that depends on it. But I do have the extended series for folks that want to
>> see the bigger picture of where this is going.
>>
>> To help organize the set, I've arranged the patches to make sort of mini sets.
>> I thought it would help reviewers break down the reviewing some. For reviewing
>> purposes, the set could be broken up into 4 different phases:
>>
>> Error code filtering (patches 1-2):
>> These two patches are all about finding and catching error codes that need to
>> be sent back up to user space before starting delayed operations.  Errors that
>> happen during a delayed operation are treated like internal errors that cause a
>> shutdown.  But we wouldnt want that for example: when the user tries to rename
>> a non existent attr.  So the idea is that we need to find all such conditions,
>> and take care of them before starting a delayed operation.
>>     xfs: Add xfs_has_attr and subroutines
>>     xfs: Check for -ENOATTR or -EEXIST
>>
>> Move transactions upwards (patches 3-12):
>> The goal of this subset is to try and move all the transaction specific code up
>> the call stack much as possible.  The idea being that once we get them to the
>> top, we can introduce the statemachine to handle the -EAGAIN logic where ever
>> the transactions used to be.
>>    xfs: Factor out new helper functions xfs_attr_rmtval_set
>>    xfs: Pull up trans handling in xfs_attr3_leaf_flipflags
>>    xfs: Split apart xfs_attr_leaf_addname
>>    xfs: Refactor xfs_attr_try_sf_addname
>>    xfs: Pull up trans roll from xfs_attr3_leaf_setflag
>>    xfs: Factor out xfs_attr_rmtval_invalidate
>>    xfs: Pull up trans roll in xfs_attr3_leaf_clearflag
>>    xfs: Refactor xfs_attr_rmtval_remove
>>    xfs: Pull up xfs_attr_rmtval_invalidate
>>    xfs: Add helper function xfs_attr_node_shrink
>>
>> Modularizing and cleanups (patches 13-22):
>> Now that we have pulled the transactions up to where we need them, it's time to
>> start breaking down the top level functions into new subfunctions. The goal
>> being to work towards a top level function that deals mostly with the
>> statemachine, and helpers for those states
>>    xfs: Remove unneeded xfs_trans_roll_inode calls
>>    xfs: Remove xfs_trans_roll in xfs_attr_node_removename
>>    xfs: Add helpers xfs_attr_is_shortform and xfs_attr_set_shortform
>>    xfs: Add helper function xfs_attr_leaf_mark_incomplete
>>    xfs: Add remote block helper functions
>>    xfs: Add helper function xfs_attr_node_removename_setup
>>    xfs: Add helper function xfs_attr_node_removename_rmt
>>    xfs: Simplify xfs_attr_leaf_addname
>>    xfs: Simplify xfs_attr_node_addname
>>    xfs: Lift -ENOSPC handler from xfs_attr_leaf_addname
> 
> I'm happy to see everything up to here merged.
> 
>> Introduce statemachine (patches 23-25):
>> Now that we have re-arranged the code such that we can remove the transaction
>> handling, we proceed to do so.  The behavior of the attr set/remove routines
>> are now also compatible as a .finish_item callback
>>    xfs: Add delay ready attr remove routines
>>    xfs: Add delay ready attr set routines
>>    xfs: Rename __xfs_attr_rmtval_remove
> 
> However, I think these still need work. The state machine mechanism
> needs more factoring so that there is a function per state/action
> that moves the state forwards one step, rather than the current
> setup where a single function might handle 3-5 different states by
> jumping to different parts of the code.
> 
> I started thinking that this was largely just code re-arrangement,
> but as I started to to do a bit of cleanup onit as an example, I
> think there's some bugs in the code that might be leading to leaking
> buffers and other such stuff. So I think this code really needs a
> good cleanup and going over before it will be ready to merge.
> 
> I've attached an untested, uncompiled patch below to demonstrate
> how I think we should start flattening this out. It takes
> xfs_attr_set_iter() and flattens it into a switch statement which
> calls fine grained functions. There are a couple of new states to
> efficiently jump into the state machine based on initial attr fork
> format, and xfs_attr_set_iter() goes away entirely.
> 
> Note that I haven't flattened the second level of function calls out
> into a function per state, which is where it's like to see this end
> up. i.e. we don't need to call through xfs_attr_leaf_addname() to
> just get to another switch statement to jump to the code that flips
> the flags.
> 
> The factoring and flattening process is the same, though: isolate
> the code that needs to run to a single function, call it from the
> state machine switch. That function then selects the next state to
> run, whether a transaction roll is necessary, etc, and the main loop
> then takes care of it from there.
> 
> Allison, if you want I can put together another couple of patches
> like the one below that flatten it right out into fine grained
> states and functions. I think having all the state machien
> transitions in one spot makes the code much easier to understand
> and, later, to simplify and optimise.

Sure, I am not opposed to alternate propositions as long as people are 
generally in agreement with the direction that its moving.  I think this 
was kind of a tough series for people to grok and review, so I certainly 
want to be mindful of everyone's feelings on it moving forward.  You are 
certainly welcome to send out some more ideas.  Let me see if I can get 
the below code compiled and getting through the test case.  Lots of 
times ideas can end up looking different in practice and it tends to 
shape opinions about how to move forward with it.  Thanks for the reviews!

Allison

> 
> Cheers,
> 
> Dave.
>