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 xfs@xxxxxxxxxxx http://oss.sgi.com/mailman/listinfo/xfs
