On Tue, Jul 15, 2025 at 02:25:35PM +0200, Christoph Hellwig wrote:
> xfs_trans_reserve_more just tries to allocate additional blocks and/or
> rtextents and is otherwise unrelated to the transaction reservation
> logic. Open code the block and rtextent reservation in
> xfs_trans_reserve_more to prepare for simplifying xfs_trans_reserve.
>
> Signed-off-by: Christoph Hellwig <hch@xxxxxx>
> ---
> fs/xfs/xfs_trans.c | 15 ++++++++++++---
> 1 file changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/fs/xfs/xfs_trans.c b/fs/xfs/xfs_trans.c
> index 8b15bfe68774..1fddea8d761a 100644
> --- a/fs/xfs/xfs_trans.c
> +++ b/fs/xfs/xfs_trans.c
> @@ -1146,9 +1146,18 @@ xfs_trans_reserve_more(
> unsigned int blocks,
> unsigned int rtextents)
> {
> - struct xfs_trans_res resv = { };
> -
> - return xfs_trans_reserve(tp, &resv, blocks, rtextents);
> + bool rsvd = tp->t_flags & XFS_TRANS_RESERVE;
> +
> + if (blocks && xfs_dec_fdblocks(tp->t_mountp, blocks, rsvd))
> + return -ENOSPC;
> + if (rtextents && xfs_dec_frextents(tp->t_mountp, rtextents) < 0) {
xfs_dec_frextents is checked for a negative return value, then why isn't
xfs_dec_fdblocks given the same treatment? Or, since IIRC both return 0
or -ENOSPC you could omit the "< 0" ?
I like how this eliminates the pointless empty resv object though.
--D
> + if (blocks)
> + xfs_add_fdblocks(tp->t_mountp, blocks);
> + return -ENOSPC;
> + }
> + tp->t_blk_res += blocks;
> + tp->t_rtx_res += rtextents;
> + return 0;
> }
>
> /*
> --
> 2.47.2
>
>
