On Thu, Aug 25, 2016 at 04:32:21PM -0700, Darrick J. Wong wrote:
> When xfs_defer_finish calls ->finish_item, it's possible that
> (refcount) won't be able to finish all the work in a single
> transaction. When this happens, the ->finish_item handler should
> shorten the log done item's list count, update the work item to
> reflect where work should continue, and return -EAGAIN so that
> defer_finish knows to retain the pending item on the pending list,
> roll the transaction, and restart processing where we left off.
>
> Plumb in the code and document how this mechanism is supposed to work.
I've voiced this before, and I will again: I think the whole xfs_defer
mechanism is a major, major mistake. All three users look somewhat
similar, but actually are different underneath. Especially the extent
free case is a lot simpler than all others, and we now place the burden
of a complex abstraction onto code that would otherwise be fairly
easily understandable.
Also it adds a memory allocation to the extent free code, and gets in
the way of merging the freed extent and extent busy structures,
something I prototyped a while ago.
|