diff options
author | Qu Wenruo <wqu@suse.com> | 2024-09-16 08:03:00 +0930 |
---|---|---|
committer | David Sterba <dsterba@suse.com> | 2024-11-11 14:34:12 +0100 |
commit | 2bca8eb0774d271b1077b72f1be135073e0a898f (patch) | |
tree | d81ab72525725c517aafdcd936d55ce840497eda /tools/perf/scripts/python/export-to-postgresql.py | |
parent | 928b4de66ed3b0d9a6f201ce41ab2eed6ea2e7ef (diff) |
btrfs: move the delalloc range bitmap search into extent_io.c
Currently for subpage (sector size < page size) cases, we reuse subpage
locked bitmap to find out all delalloc ranges we have locked, and run
all those found ranges.
However such reuse is not perfect, e.g.:
0 32K 64K 96K 128K
| |////////||///////| |////|
120K
For above range, writepage_delalloc() for page 0 will handle the range
[32K, 96k), note delalloc range can be beyond the page boundary.
But writepage_delalloc() for page 64K will only handle range [120K,
128K), as the previous run on page 0 has already handled range [64K,
96K).
Meanwhile for the writeback we should expect range [64K, 96K) to also be
locked, this leads to the mismatch from locked bitmap and delalloc
range.
This is not causing problems yet, but it's still an inconsistent
behavior.
So instead of relying on the subpage locked bitmap, move the delalloc
range search using local @delalloc_bitmap, so that we can remove the
existing btrfs_folio_find_writer_locked().
Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Diffstat (limited to 'tools/perf/scripts/python/export-to-postgresql.py')
0 files changed, 0 insertions, 0 deletions