Re: xfs_bmap_extents_to_btree allocation warnings

[Dave Chinner <david@fromorbit.com>]

On Mon, Jan 10, 2022 at 07:41:52PM +1100, Dave Chinner wrote:
> On Thu, Jan 06, 2022 at 12:52:28AM -0800, Krister Johansen wrote:
> > On Thu, Jan 06, 2022 at 12:01:23PM +1100, Dave Chinner wrote:
> > > On Tue, Jan 04, 2022 at 11:10:52PM -0800, Krister Johansen wrote:
> > > So 1,871,665 of 228,849,020 blocks free in the AG. That's 99.2%
> > > full, so it's extremely likely you are hitting a full AG condition.
> > > 
> > > /me goes and looks at xfs_iomap_write_direct()....
> > > 
> > > .... and notices that it passes "0" as the total allocation block
> > > count, which means it isn't reserving space in the AG for both the
> > > data extent and the BMBT blocks...
> > > 
> > > ... and several other xfs_bmapi_write() callers have the same
> > > issue...
> > > 
> > > Ok, let me spend a bit more looking into this in more depth, but it
> > > looks like the problem is at the xfs_bmapi_write() caller level, not
> > > deep in the allocator itself.
> > 
> > At least on 5.4 xfs_bmapi_write is still passing resblks instead of
> > zero, which is computed in xfs_iomap_write_direct.
> 
> yup, I missed commit da781e64b28c ("xfs: don't set bmapi total block
> req where minleft is") back in 2019 where that behaviour was
> changed, and instead it changes xfs_bmapi_write() to implcitly
> manage space for BMBT blocks via args->minleft whilst still
> explicitly requiring the caller to reserve those blocks at
> transaction allocation time.

FWIW, I should have said here that you should really add that commit
to your current tree and see if that fixes the problem...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com