]> git.ipfire.org Git - thirdparty/linux.git/commit
btrfs: reloc: unconditionally invalidate the page cache for each cluster
authorQu Wenruo <wqu@suse.com>
Tue, 15 Jul 2025 03:48:39 +0000 (13:18 +0930)
committerDavid Sterba <dsterba@suse.com>
Mon, 21 Jul 2025 23:13:03 +0000 (01:13 +0200)
commit4e346baee95f4688b36c9bd95664774c3d105c3d
tree354c4b724781ca46589bf53275bbab6830592828
parent009b2056cb259c90426b3c57e5b145d1cd9fa9e2
btrfs: reloc: unconditionally invalidate the page cache for each cluster

Commit 9d9ea1e68a05 ("btrfs: subpage: fix relocation potentially
overwriting last page data") fixed a bug when relocating data block
groups for subpage cases.

However for the incoming large folios for data reloc inode, we can hit
the same situation where block size is the same as page size, but the
folio we got is still larger than a block.

In that case, the old subpage specific check is no longer reliable.

Here we have to enhance the handling by:

- Unconditionally invalidate the page cache for the current cluster
  We set the @flush to true so that any dirty folios are properly
  written back first.

  And this time instead of dropping the whole page cache, just drop the
  range covered by the current cluster.

  This will bring some minor performance drop, as for a large folio, the
  heading half will be read twice (read by previous cluster, then
  invalidated, then read again by the current cluster).

  However that is required to support large folios, and this gets rid of
  the kinda tricky manual uptodate flag clearing for each block.

- Remove the special handling of writing back the whole page cache
  filemap_invalidate_inode() handles the write back already, and since
  we're invalidating all pages in the range, we no longer need to
  manually clear the uptodate flags for involved blocks.

  Thus there is no need to manually write back the whole page cache.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
fs/btrfs/relocation.c