In the segment appender we dynamically compute the size to which we fallocate the segment based on the maximum size. When we introduced segment size clamping, we forgot to apply it here which led to it to use the non-clamped value leading to unexpected behavior like the one reported below:
We see that the current segment has been fallocated/ftruncated to
32MiB. The segments still get closed at 16MiB at which point they are
being shrunk. This still wastes lots of preallocation which isn't cheap
and obviously also wastes disk space for the active segment.
—@StephanDollberg
(cherry picked from commit 20d5695c58d4c778724ab47b6eeb3fe3163e4e05)
Backports Required
[ ] none - not a bug fix
[x] none - this is a backport
[ ] none - issue does not exist in previous branches
[ ] none - papercut/not impactful enough to backport
23462
In the segment appender we dynamically compute the size to which we fallocate the segment based on the maximum size. When we introduced segment size clamping, we forgot to apply it here which led to it to use the non-clamped value leading to unexpected behavior like the one reported below:
(cherry picked from commit 20d5695c58d4c778724ab47b6eeb3fe3163e4e05)
Backports Required
Release Notes
none