]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
xfs: restrict when we try to align cow fork delalloc to cowextsz hints
authorDarrick J. Wong <djwong@kernel.org>
Wed, 30 Apr 2025 21:27:03 +0000 (14:27 -0700)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Fri, 9 May 2025 07:41:38 +0000 (09:41 +0200)
commit227bda0fd069986fadbef493ade6770fca580694
tree1df990ef0ce34d5b4f1778314809ae66b361b0d3
parent6724a3faa8ebea07970baf5c33acf1d957bb1413
xfs: restrict when we try to align cow fork delalloc to cowextsz hints

[ Upstream commit 288e1f693f04e66be99f27e7cbe4a45936a66745 ]

xfs/205 produces the following failure when always_cow is enabled:

#  --- a/tests/xfs/205.out 2024-02-28 16:20:24.437887970 -0800
#  +++ b/tests/xfs/205.out.bad 2024-06-03 21:13:40.584000000 -0700
#  @@ -1,4 +1,5 @@
#   QA output created by 205
#   *** one file
#  +   !!! disk full (expected)
#   *** one file, a few bytes at a time
#   *** done

This is the result of overly aggressive attempts to align cow fork
delalloc reservations to the CoW extent size hint.  Looking at the trace
data, we're trying to append a single fsblock to the "fred" file.
Trying to create a speculative post-eof reservation fails because
there's not enough space.

We then set @prealloc_blocks to zero and try again, but the cowextsz
alignment code triggers, which expands our request for a 1-fsblock
reservation into a 39-block reservation.  There's not enough space for
that, so the whole write fails with ENOSPC even though there's
sufficient space in the filesystem to allocate the single block that we
need to land the write.

There are two things wrong here -- first, we shouldn't be attempting
speculative preallocations beyond what was requested when we're low on
space.  Second, if we've already computed a posteof preallocation, we
shouldn't bother trying to align that to the cowextsize hint.

Fix both of these problems by adding a flag that only enables the
expansion of the delalloc reservation to the cowextsize if we're doing a
non-extending write, and only if we're not doing an ENOSPC retry.  This
requires us to move the ENOSPC retry logic to xfs_bmapi_reserve_delalloc.

I probably should have caught this six years ago when 6ca30729c206d was
being reviewed, but oh well.  Update the comments to reflect what the
code does now.

Fixes: 6ca30729c206d ("xfs: bmap code cleanup")
Signed-off-by: Darrick J. Wong <djwong@kernel.org>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Chandan Babu R <chandanbabu@kernel.org>
Signed-off-by: Leah Rumancik <leah.rumancik@gmail.com>
Acked-by: "Darrick J. Wong" <djwong@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/xfs/libxfs/xfs_bmap.c
fs/xfs/xfs_iomap.c