| Message ID | 20240820170517.528181-7-hch@lst.de (mailing list archive) |
|---|---|
| State | Superseded, archived |
| Headers | show |
| Series | [1/6] xfs: merge xfs_attr_leaf_try_add into xfs_attr_leaf_addname | expand |
On Tue, Aug 20, 2024 at 07:04:57PM +0200, Christoph Hellwig wrote: > Currently the debug-only xfs_bmap_exact_minlen_extent_alloc allocation > variant fails to drop into the lowmode last restor allocator, and last resort? > thus can sometimes fail allocations for which the caller has a > transaction block reservation. > > Fix this by using xfs_bmap_btalloc_low_space to do the actual allocation. > > Signed-off-by: Christoph Hellwig <hch@lst.de> > --- > fs/xfs/libxfs/xfs_bmap.c | 8 +++++++- > 1 file changed, 7 insertions(+), 1 deletion(-) > > diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c > index b5eeaea164ee46..784dd5dda2a1a2 100644 > --- a/fs/xfs/libxfs/xfs_bmap.c > +++ b/fs/xfs/libxfs/xfs_bmap.c > @@ -3493,7 +3493,13 @@ xfs_bmap_exact_minlen_extent_alloc( > */ > ap->blkno = XFS_AGB_TO_FSB(ap->ip->i_mount, 0, 0); > > - return xfs_alloc_vextent_first_ag(args, ap->blkno); > + /* > + * Use the low space allocator as it first does a "normal" AG iteration > + * and then drops the reservation to minlen, which might be required to > + * find an allocation for the transaction reservation when the file > + * system is very full. Isn't it already doing a minlen allocation? Oh, that probably refers to shrinking args->total, doesn't it. If the answer to that is 'yes' then Reviewed-by: Darrick J. Wong <djwong@kernel.org> --D > + */ > + return xfs_bmap_btalloc_low_space(ap, args); > } > #else > > -- > 2.43.0 > >
On Wed, Aug 21, 2024 at 09:07:23AM -0700, Darrick J. Wong wrote: > On Tue, Aug 20, 2024 at 07:04:57PM +0200, Christoph Hellwig wrote: > > Currently the debug-only xfs_bmap_exact_minlen_extent_alloc allocation > > variant fails to drop into the lowmode last restor allocator, and > > last resort? Yes. > > + /* > > + * Use the low space allocator as it first does a "normal" AG iteration > > + * and then drops the reservation to minlen, which might be required to > > + * find an allocation for the transaction reservation when the file > > + * system is very full. > > Isn't it already doing a minlen allocation? Oh, that probably refers to > shrinking args->total, doesn't it. Yes, without this patch ap->total is left at the full value and never reduced.
diff --git a/fs/xfs/libxfs/xfs_bmap.c b/fs/xfs/libxfs/xfs_bmap.c index b5eeaea164ee46..784dd5dda2a1a2 100644 --- a/fs/xfs/libxfs/xfs_bmap.c +++ b/fs/xfs/libxfs/xfs_bmap.c @@ -3493,7 +3493,13 @@ xfs_bmap_exact_minlen_extent_alloc( */ ap->blkno = XFS_AGB_TO_FSB(ap->ip->i_mount, 0, 0); - return xfs_alloc_vextent_first_ag(args, ap->blkno); + /* + * Use the low space allocator as it first does a "normal" AG iteration + * and then drops the reservation to minlen, which might be required to + * find an allocation for the transaction reservation when the file + * system is very full. + */ + return xfs_bmap_btalloc_low_space(ap, args); } #else
Currently the debug-only xfs_bmap_exact_minlen_extent_alloc allocation variant fails to drop into the lowmode last restor allocator, and thus can sometimes fail allocations for which the caller has a transaction block reservation. Fix this by using xfs_bmap_btalloc_low_space to do the actual allocation. Signed-off-by: Christoph Hellwig <hch@lst.de> --- fs/xfs/libxfs/xfs_bmap.c | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-)