]> git.ipfire.org Git - thirdparty/kernel/stable.git/commit
btrfs: remove btrfs_fs_info::sectors_per_page
authorQu Wenruo <wqu@suse.com>
Mon, 12 Jan 2026 14:55:52 +0000 (09:55 -0500)
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>
Sat, 17 Jan 2026 15:31:26 +0000 (16:31 +0100)
commit7216d78ca34f1264d153e685148826d4a94c8d45
tree3f4b66191ca2844bd55e4512a18048a22f35214f
parentced5459df05a19646b0ac890fe25505acb43b2e3
btrfs: remove btrfs_fs_info::sectors_per_page

[ Upstream commit 619611e87fcca1fdaa67c2bf6b030863ab90216e ]

For the future large folio support, our filemap can have folios with
different sizes, thus we can no longer rely on a fixed blocks_per_page
value.

To prepare for that future, here we do:

- Remove btrfs_fs_info::sectors_per_page

- Introduce a helper, btrfs_blocks_per_folio()
  Which uses the folio size to calculate the number of blocks for each
  folio.

- Migrate the existing btrfs_fs_info::sectors_per_page to use that
  helper
  There are some exceptions:

  * Metadata nodesize < page size support
    In the future, even if we support large folios, we will only
    allocate a folio that matches our nodesize.
    Thus we won't have a folio covering multiple metadata unless
    nodesize < page size.

  * Existing subpage bitmap dump
    We use a single unsigned long to store the bitmap.
    That means until we change the bitmap dumping code, our upper limit
    for folio size will only be 256K (4K block size, 64 bit unsigned
    long).

  * btrfs_is_subpage() check
    This will be migrated into a future patch.

Signed-off-by: Qu Wenruo <wqu@suse.com>
Reviewed-by: David Sterba <dsterba@suse.com>
Signed-off-by: David Sterba <dsterba@suse.com>
Stable-dep-of: e9e3b22ddfa7 ("btrfs: fix beyond-EOF write handling")
Signed-off-by: Sasha Levin <sashal@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
fs/btrfs/disk-io.c
fs/btrfs/extent_io.c
fs/btrfs/fs.h
fs/btrfs/subpage.c