summaryrefslogtreecommitdiff
path: root/include/net/aligned_data.h
diff options
context:
space:
mode:
authorQu Wenruo <wqu@suse.com>2026-01-12 09:55:52 -0500
committerGreg Kroah-Hartman <gregkh@linuxfoundation.org>2026-01-17 16:31:26 +0100
commit7216d78ca34f1264d153e685148826d4a94c8d45 (patch)
tree3f4b66191ca2844bd55e4512a18048a22f35214f /include/net/aligned_data.h
parentced5459df05a19646b0ac890fe25505acb43b2e3 (diff)
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>
Diffstat (limited to 'include/net/aligned_data.h')
0 files changed, 0 insertions, 0 deletions