| Message ID | 09481f8720302e0c4aaee7e460c142f632c72fe8.1692858397.git.wqu@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | btrfs: make extent buffer memory continuous | expand |
On 8/24/23 14:33, Qu Wenruo wrote: > A long time ago, we have some metadata chunks which starts at sector > boundary but not aligned at nodesize boundary. > > + if (!IS_ALIGNED(start, fs_info->nodesize) && > + !test_and_set_bit(BTRFS_FS_UNALIGNED_TREE_BLOCK, > + &fs_info->flags)) { > + btrfs_warn(fs_info, > + "tree block not nodesize aligned, start %llu nodesize %u", > + start, fs_info->nodesize); > + btrfs_warn(fs_info, "this can be solved by a full metadata balance"); > + } > return 0; I don't know if ratelimited is required here. But, that shouldn't be a no-go for the patch. Reviewed-by: Anand Jain <anand.jain@oracle.com> Thanks.
On Wed, Sep 06, 2023 at 05:34:15PM +0800, Anand Jain wrote: > On 8/24/23 14:33, Qu Wenruo wrote: > > A long time ago, we have some metadata chunks which starts at sector > > boundary but not aligned at nodesize boundary. > > > > + if (!IS_ALIGNED(start, fs_info->nodesize) && > > + !test_and_set_bit(BTRFS_FS_UNALIGNED_TREE_BLOCK, > > + &fs_info->flags)) { > > + btrfs_warn(fs_info, > > + "tree block not nodesize aligned, start %llu nodesize %u", > > + start, fs_info->nodesize); > > + btrfs_warn(fs_info, "this can be solved by a full metadata balance"); > > + } > > return 0; > > I don't know if ratelimited is required here. But, that shouldn't be a > no-go for the patch. There will be only one such message as it's tracked by the global state bit BTRFS_FS_UNALIGNED_TREE_BLOCK. However the message should be printed in one go so it's not mixed with other system messages.
diff --git a/fs/btrfs/extent_io.c b/fs/btrfs/extent_io.c index ac3fca5a5e41..f13211975e0b 100644 --- a/fs/btrfs/extent_io.c +++ b/fs/btrfs/extent_io.c @@ -3462,6 +3462,14 @@ static int check_eb_alignment(struct btrfs_fs_info *fs_info, u64 start) start, fs_info->nodesize); return -EINVAL; } + if (!IS_ALIGNED(start, fs_info->nodesize) && + !test_and_set_bit(BTRFS_FS_UNALIGNED_TREE_BLOCK, + &fs_info->flags)) { + btrfs_warn(fs_info, + "tree block not nodesize aligned, start %llu nodesize %u", + start, fs_info->nodesize); + btrfs_warn(fs_info, "this can be solved by a full metadata balance"); + } return 0; } diff --git a/fs/btrfs/fs.h b/fs/btrfs/fs.h index a523d64d5491..4dc16d74437c 100644 --- a/fs/btrfs/fs.h +++ b/fs/btrfs/fs.h @@ -139,6 +139,13 @@ enum { */ BTRFS_FS_FEATURE_CHANGED, + /* + * Indicate if we have tree block which is only aligned to sectorsize, + * but not to nodesize. + * This should be rare nowadays. + */ + BTRFS_FS_UNALIGNED_TREE_BLOCK, + #if BITS_PER_LONG == 32 /* Indicate if we have error/warn message printed on 32bit systems */ BTRFS_FS_32BIT_ERROR,
A long time ago, we have some metadata chunks which starts at sector boundary but not aligned at nodesize boundary. This led to some older fs which can have tree blocks only aligned to sectorsize, but not nodesize. Later btrfs check gained the ability to detect and warn about such tree blocks, and kernel fixed the chunk allocation behavior, nowadays those tree blocks should be pretty rare. But in the future, if we want to migrate metadata to folio, we can not have such tree blocks, as filemap_add_folio() requires the page index to be aligned with the folio number of pages. (AKA, such unaligned tree blocks can lead to VM_BUG_ON().) So this patch adds extra warning for those unaligned tree blocks, as a preparation for the future folio migration. Signed-off-by: Qu Wenruo <wqu@suse.com> --- fs/btrfs/extent_io.c | 8 ++++++++ fs/btrfs/fs.h | 7 +++++++ 2 files changed, 15 insertions(+)