]> git.baikalelectronics.ru Git - kernel.git/commit
btrfs: defrag: don't use merged extent map for their generation check
authorQu Wenruo <wqu@suse.com>
Fri, 11 Feb 2022 06:46:13 +0000 (14:46 +0800)
committerDavid Sterba <dsterba@suse.com>
Wed, 23 Feb 2022 16:43:13 +0000 (17:43 +0100)
commit86c7cb025443d953980184ba27d5cd7a1da7eac5
tree51f8aacf152be18ac4b2944a600ad76b6f28d1ae
parent5e9e984172624f8e0151fcf4ad12ae1829e2fbfe
btrfs: defrag: don't use merged extent map for their generation check

For extent maps, if they are not compressed extents and are adjacent by
logical addresses and file offsets, they can be merged into one larger
extent map.

Such merged extent map will have the higher generation of all the
original ones.

But this brings a problem for autodefrag, as it relies on accurate
extent_map::generation to determine if one extent should be defragged.

For merged extent maps, their higher generation can mark some older
extents to be defragged while the original extent map doesn't meet the
minimal generation threshold.

Thus this will cause extra IO.

So solve the problem, here we introduce a new flag, EXTENT_FLAG_MERGED,
to indicate if the extent map is merged from one or more ems.

And for autodefrag, if we find a merged extent map, and its generation
meets the generation requirement, we just don't use this one, and go
back to defrag_get_extent() to read extent maps from subvolume trees.

This could cause more read IO, but should result less defrag data write,
so in the long run it should be a win for autodefrag.

Reviewed-by: Filipe Manana <fdmanana@suse.com>
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/extent_map.c
fs/btrfs/extent_map.h
fs/btrfs/ioctl.c