Re: [PATCH 2/2] xfs: Limit total allocation request to maximum possible

[Dave Chinner <david@fromorbit.com>]

On Wed, Sep 18, 2019 at 10:24:53AM +0200, Carlos Maiolino wrote:
> The original allocation request may have a total value way beyond
> possible limits.
> 
> Trim it down to the maximum possible if needed
> 
> Signed-off-by: Carlos Maiolino <cmaiolino@redhat.com>
> ---
>  fs/xfs/libxfs/xfs_bmap.c | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c
> index 07aad70f3931..3aa0bf5cc7e3 100644
> --- a/fs/xfs/libxfs/xfs_bmap.c
> +++ b/fs/xfs/libxfs/xfs_bmap.c
> @@ -3477,6 +3477,11 @@ xfs_bmap_btalloc(
>  			error = xfs_bmap_btalloc_filestreams(ap, &args, &blen);
>  		else
>  			error = xfs_bmap_btalloc_nullfb(ap, &args, &blen);
> +
> +		/* We can never have total larger than blen, so trim it now */

Yes we can. blen is typically the largest contiguous extent in the
filesystem or AG in question. It is not typically the total free
space in the AG, which only occurs when the AG is empty. i.e. in
normal situations, we can allocate both blen and the rest of the
metadata from the same AG as there is more than one free extent in
the AG.

I think that for the purposes of a single > AG size allocation, the
total needs to be clamped to the free space in the AG that is
selected, not the length of the allocation we are trying....

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com