> + * 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. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
