[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230816034543.GS2247938@mit.edu>
Date: Tue, 15 Aug 2023 23:45:43 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Kemeng Shi <shikemeng@...weicloud.com>
Cc: adilger.kernel@...ger.ca, linux-ext4@...r.kernel.org,
linux-kernel@...r.kernel.org
Subject: Re: [PATCH 11/13] ext4: correct gdblock calculation in
add_new_gdb_meta_bg to support non first group
On Thu, Jun 29, 2023 at 08:00:42PM +0800, Kemeng Shi wrote:
> In add_new_gdb_meta_bg, we assume that group could be non first
> group in meta block group as we call ext4_meta_bg_first_block_no
> to get first block of meta block group rather than call
> ext4_group_first_block_no for passed group directly. Then ext4_bg_has_super
> should be called with first group in meta group rather than new added
> group. Or we can call ext4_group_first_block_no instead of
> ext4_meta_bg_first_block_no to assume only first group of
> meta group will be passed.
> Either way, ext4_meta_bg_first_block_no will be useless and
> could be removed.
Unfortunately, I spent more time trying to understand the commit
description than the C code. Perhaps this might be a better way of
describing the situation?
The ext4_new descs() function calls ext4_meta_bg_first_block_no() with
the group paramter when the group is the first group of a meta_bg
(e.g., when (group % EXT4_DESC_PER_BLOCK) is zero. So we can simplify
things a bit by removing ext4_meta_bg_first_block_no() and an open
coding its logic.
Does this make more sense to tou?
- Ted
Powered by blists - more mailing lists