The balloon holds filesystem space that never carries data, but its
blocks are allocated, so FITRIM walks past them, and inflating the
balloon is a plain fallocate() that does not discard either. Once the
balloon is inflated over the blocks of removed files, e.g. on an online
shrink of a Container disk, the ploop or qcow2 image keeps those
clusters mapped for good, and compaction, which is FITRIM, does not
give them back (VSTOR-153590).
This series makes FITRIM discard the unwritten extents of the balloon
after the free space, on ext4 (patch 4) and xfs (patch 5). The walk
holds the inode locks of the balloon exclusively, after waiting for
direct I/O and flushing its page cache, as punch hole does, so no block
can be freed, reused or written under the discard. Physically adjacent
extents are merged, so that the device below gets whole clusters, and
a long run is discarded in interruptible chunks. A balloon inflated
before this series is released by the next FITRIM, no userspace change
is needed. Patch 3 fixes an inode reference leak in xfs_balloon_get()
that FITRIM would now hit too.
Patches 1 and 2 are mainline fixes of the xfs FITRIM free space walk,
merged for 7.4-rc2 with Cc: stable. hci-8.1 carries the RHEL backport
of b0ffe661fab4 ("xfs: fix performance problems when fstrimming a
subset of a fragmented AG") and has both bugs. The ploop tests ran into
the second one: of several free extents of the longest length in an AG
only one is discarded, so whether FITRIM gives the space back depends
on where xfs put the files. The first one makes later batches of a
whole-AG walk skip the free extents below the block they restart from.
The ploop side is a stack of openvz/ploop.ovz PRs, 523, 520, 521 and
519. PR 519 holds the tests for this series and goes in after it:
https://bitbucket.org/openvz/ploop.ovz/pull-requests/519
Changes since v2
(https://lore.virtuozzo.com/kernel/[email protected]/):
- add the mainline xfs FITRIM fixes as patches 1 and 2;
- skip an empty balloon before taking its locks. A non-empty one is
still walked whole on every FITRIM, whatever the range; the notes in
patches 4 and 5 say why (Sashiko);
- xfs: convert minlen to sectors in 64 bits (Sashiko).
Tested on 6.12.0-211.52.1.22.19.vz10 rebuilt with this series and the
VSTOR-154159 max_discard_segments fixes:
- test_ploop_balloon.py of PR 519 on ploop and qcow2 images with ext4
and xfs is green, dmesg is clean. It covers discarding the space under
a balloon inflated over removed data, deflating it and writing over
it, online and offline shrink, and free runs a few clusters long
released by a default discard. The xfs case of the last one fails on
v2 of this series, without patches 1 and 2, on both image formats;
- the fstrim time and SIGKILL checks of v2 were not repeated: the walk
itself did not change.
Not covered: ext4 bigalloc, a realtime xfs balloon (skipped). On ploop1
discard works on whole clusters, so up to two clusters at the ends of
each contiguous piece of the balloon stay mapped, as do pieces shorter
than the FITRIM minimum length.
Daejun Park (2):
ms/xfs: don't skip free extents in later batches of a whole-AG FITRIM
ms/xfs: don't skip free extents of the longest length in a whole-AG
FITRIM
Denis V. Lunev (3):
xfs: release the balloon inode when xfs_balloon_get() refuses it
ext4: discard the balloon on FITRIM
xfs: discard the balloon on FITRIM
fs/ext4/mballoc.c | 126 ++++++++++++++++++++++++++++++++
fs/xfs/xfs_discard.c | 170 +++++++++++++++++++++++++++++++++++++++++--
fs/xfs/xfs_super.c | 4 +-
3 files changed, 291 insertions(+), 9 deletions(-)
--
2.53.0
_______________________________________________
Devel mailing list
[email protected]
https://lists.openvz.org/mailman/listinfo/devel
