Re: [PATCH 04/71] xfs: defer should allow ->finish_item to request a new transaction

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.

_______________________________________________
xfs mailing list
[email protected]
http://oss.sgi.com/mailman/listinfo/xfs