[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230316050740.GL860405@mit.edu>
Date: Thu, 16 Mar 2023 01:07:40 -0400
From: "Theodore Ts'o" <tytso@....edu>
To: Kemeng Shi <shikemeng@...weicloud.com>
Cc: adilger.kernel@...ger.ca, ojaswin@...ux.ibm.com,
ritesh.list@...il.com,
Harshad Shirwadkar <harshadshirwadkar@...il.com>,
linux-ext4@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 20/20] ext4: simplify calculation of blkoff in
ext4_mb_new_blocks_simple
On Sat, Mar 04, 2023 at 01:21:20AM +0800, Kemeng Shi wrote:
> We try to allocate a block from goal in ext4_mb_new_blocks_simple. We
> only need get blkoff in first group with goal and set blkoff to 0 for
> the rest groups.
>
> Signed-off-by: Kemeng Shi <shikemeng@...weicloud.com>
While this patch is OK as a simplification, there's a bigger problem
with ext4_mb_new_blocks_simple(), and that is that we start looking
for free blocks starting at the goal block, and then if we can't any
free blocks by the time we get to the last block group.... we stop,
and return ENOSPC.
This function is only used in the fast commit replay path, but for a
very full file system, this could cause a fast commit replay to fail
unnecesarily. What we need to do is to try wrapping back to the
beginning of the file system, and stop when we hit the original group
(of the goal block) minus one.
We can fix this up in a separate patch, since this doesn't make things
any worse, but essentially we need to do something like this:
maxgroups = ext4_get_groups_count(sb);
for (g = 0; g < maxgroups ; g++) {
...
group++;
if (group > maxgroups)
group = 0;
}
- Ted
Powered by blists - more mailing lists