summaryrefslogtreecommitdiff
path: root/tools/perf/scripts/python
diff options
context:
space:
mode:
authorFilipe Manana <fdmanana@suse.com>2026-09-14 18:11:30 +0100
committerDavid Sterba <dsterba@suse.com>2026-09-16 15:56:02 +0200
commitcc337324cc6be1ce0ae7e5a068dcb7e99ae1b59c (patch)
tree47d54de343d797f14272f4890f5d3b2b14aa5f64 /tools/perf/scripts/python
parentf59d86d25e41c5ac511584d9d6808ee448fd42b0 (diff)
downloadlinux-next-cc337324cc6be1ce0ae7e5a068dcb7e99ae1b59c.tar.gz
linux-next-cc337324cc6be1ce0ae7e5a068dcb7e99ae1b59c.zip
btrfs: fix creation of compressed inline extents that don't save space
If the compressed data of an inline extent is larger than or equals to the size of the uncompressed data, we are still allowing the creation of the compressed inline extent, which does not result in any benefits, quite the contrary as we waste metadata space and have to decompress when reading. This is a recent regression introduced in commit 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper"). It happens because we are passing the block size to btrfs_compress_bio(), so we don't get -E2BIG from the compression code anymore, but we can not pass i_size either, because if i_size is smaller than sector size, we end up never creating lzo compressed inline extent for such small i_size values. So refuse the compressed result at run_delalloc_inline() if its size is not smaller than the uncompressed size (i_size). Reported-by: Hanabishi <i.r.e.c.c.a.k.u.n+kernel.org@gmail.com> Link: https://lore.kernel.org/linux-btrfs/c97652a5-ac6b-4de6-aa23-3cdebc01d00b@gmail.com/ Fixes: 3eaf5f082c4c ("btrfs: extract inlined creation into a dedicated delalloc helper") CC: stable@vger.kernel.org # 7.1+ Reviewed-by: Qu Wenruo <wqu@suse.com> Signed-off-by: Filipe Manana <fdmanana@suse.com> Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python')
0 files changed, 0 insertions, 0 deletions