Re: [PATCH 11/47] xfs: move deferred operations into a separate file

[Christoph Hellwig <hch@xxxxxxxxxxxxx>]

> + * NOTE: To avoid exceeding the transaction reservation, we limit the
> + * number of items that we attach to a given xfs_defer_pending.

This seems like a new feature compared to the old bmap_free code,
can you explain it it in a little more detail?  As I'm trying to compare
this code to the existing one there are a few things that confuse me,
most importantly the purpose of the xfs_defer_pending structure,
which seems like a new indirection.  I don't really like that
indirection at all, as it introduces another memory allocation deep
down in the commit path where we can't recover from ENOMEM.  Also there
seems to be a 1:1 relationship between it and the xfs_bmap_free_item
structure that got renamed to xfs_extent_free_item.

> +static const struct xfs_defer_op_type 
> *defer_op_types[XFS_DEFER_OPS_TYPE_MAX];

We shouldn't really need this global array and the xfs_defer_ops_type
enum, just pass the xfs_defer_op_type pointer into xfs_defer_add.