Re: [PATCH] xfs: handle nimaps=0 from xfs_bmapi_write in xfs_alloc_file_space

[Christoph Hellwig <hch@lst.de>]

On Mon, Oct 09, 2023 at 09:27:56AM -0700, Darrick J. Wong wrote:
> > +		/*
> > +		 * If xfs_bmapi_write finds a delalloc extent at the requested
> > +		 * range, it tries to convert the entire delalloc extent to a
> > +		 * real allocation.
> > +		 * But if the allocator then can't find an AG with enough space
> > +		 * to at least cover the start block of the requested range,
> 
> Hmm.  Given that you said this was done in the context of delalloc on
> the realtime volume, I don't think there are AGs in play here?  Unless
> the AG actually ran out of space allocating a bmbt block?

Well, really rt group as it was using your rt group patches.  Just
using AG as the more generalized case here.

> My hunch here is that free space on the rt volume is fragmented, but
> there were still enough free rtextents to create a large delalloc
> reservation.  Conversion of the reservation to an unwritten extent
> managed to map one free rtextent into the file, but not enough to
> convert the file mapping all the way to @startoffset_fsb.  Hence the
> bmapi_write call succeeds, but returns @nmaps == 0.

Yes.

> If that's true, I suggest changing the second sentence of the comment to
> read:
> 
> "If the allocator cannot find a single free extent large enough to
> cover the start block of the requested range, xfs_bmapi_write will
> return 0 but leave *nimaps set to 0."

That's probably better indeed.  I'll wait a bit for more comment
and will resend with that update.