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.
