diff options
author | Josef Bacik <josef@toxicpanda.com> | 2021-11-18 16:33:14 -0500 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2022-01-03 15:09:46 +0100 |
commit | 950575c023aabfeac506cae02917c32eae1f553e (patch) | |
tree | 2a1d27e91cdfc69dfc39ad3a02afe97af0c5dc37 /fs/btrfs/subpage.c | |
parent | 83f1b68002c208329412cf9f998c90b3326828d2 (diff) | |
download | linux-950575c023aabfeac506cae02917c32eae1f553e.tar.gz linux-950575c023aabfeac506cae02917c32eae1f553e.tar.bz2 linux-950575c023aabfeac506cae02917c32eae1f553e.zip |
btrfs: only use ->max_extent_size if it is set in the bitmap
While adding self tests for my space index change I was hitting a
problem where the space indexed tree wasn't returning the expected
->max_extent_size. This is because we will skip searching any entry
that doesn't have ->bytes >= the amount of bytes we want. However we'll
still set the max_extent_size based on that entry. The problem is if we
don't search the bitmap we won't have ->max_extent_size set properly, so
we can't really trust it.
This doesn't really result in a problem per-se, it can just result in us
not finding contiguous area that may exist. Fix the max_extent_size
helper to return ->bytes if ->max_extent_size isn't set, and add a big
comment explaining why we're doing this.
Signed-off-by: Josef Bacik <josef@toxicpanda.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'fs/btrfs/subpage.c')
0 files changed, 0 insertions, 0 deletions