[<prev] [next>] [day] [month] [year] [list]
Message-Id: <6B41BA7B-1BF4-471E-AA3B-D4CEFB7335B8@gmail.com>
Date: Mon, 12 Feb 2018 09:14:33 +0300
From: Alexey Lyashkov <alexey.lyashkov@...il.com>
To: Ts'o Theodore <tytso@....edu>
Cc: linux-ext4 <linux-ext4@...r.kernel.org>
Subject: probably bug in block allocator
Hi ext4 developers,
I looked into problem with long time allocations with large FS and found a some strange in
commit
commit 40ae3487628235e5f1eb27542cca0cdb6e5dbe16
Author: Theodore Ts'o <tytso@....edu>
Date: Mon Feb 4 15:08:40 2013 -0500
ext4: optimize mballoc for large allocations
..
it have a chunk
@@ -1884,15 +1884,19 @@ static int ext4_mb_good_group(struct ext4_allocation_context *ac,
case 0:
BUG_ON(ac->ac_2order == 0);
- if (grp->bb_largest_free_order < ac->ac_2order)
- return 0;
-
/* Avoid using the first bg of a flexgroup for data files */
if ((ac->ac_flags & EXT4_MB_HINT_DATA) &&
(flex_size >= EXT4_FLEX_SIZE_DIR_ALLOC_SCHEME) &&
((group % flex_size) == 0))
return 0;
+ if ((ac->ac_2order > ac->ac_sb->s_blocksize_bits+1) ||
+ (free / fragments) >= ac->ac_g_ex.fe_len) <<<< (0)
+ return 1;
+
+ if (grp->bb_largest_free_order < ac->ac_2order)
+ return 0;
+
return 1;
case 1:
if ((free / fragments) >= ac->ac_g_ex.fe_len) (1)
..
ac_g_ex isn’t changed between loops, free/fragments is also don’t changed.
i this case loop(1) is useless as same condition as used in loop (0), but it’s will eats a some time with large number a group.
In this case - i think loop(1) can be cut and save a some time with scanning a groups.
Theo, what you think about that change ?
Alex
Powered by blists - more mailing lists