mirror of
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git
synced 2024-09-04 09:59:32 +00:00
ext4: fix stripe-unaligned allocations
When a filesystem is created using: mkfs.ext4 -b 4096 -E stride=512 <dev> and we try to allocate 64MB extent, we will end up directly in ext4_mb_complex_scan_group(). This is because the request is detected as power-of-two allocation (so we start in ext4_mb_regular_allocator() with ac_criteria == 0) however the check before ext4_mb_simple_scan_group() refuses the direct buddy scan because the allocation request is too large. Since cr == 0, the check whether we should use ext4_mb_scan_aligned() fails as well and we fall back to ext4_mb_complex_scan_group(). Fix the problem by checking for upper limit on power-of-two requests directly when detecting them. Reported-by: Ross Zwisler <ross.zwisler@linux.intel.com> Signed-off-by: Jan Kara <jack@suse.cz> Signed-off-by: Theodore Ts'o <tytso@mit.edu>
This commit is contained in:
parent
168316db35
commit
d9b22cf9f5
1 changed files with 4 additions and 2 deletions
|
@ -2146,8 +2146,10 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
|
|||
* We search using buddy data only if the order of the request
|
||||
* is greater than equal to the sbi_s_mb_order2_reqs
|
||||
* You can tune it via /sys/fs/ext4/<partition>/mb_order2_req
|
||||
* We also support searching for power-of-two requests only for
|
||||
* requests upto maximum buddy size we have constructed.
|
||||
*/
|
||||
if (i >= sbi->s_mb_order2_reqs) {
|
||||
if (i >= sbi->s_mb_order2_reqs && i <= sb->s_blocksize_bits + 2) {
|
||||
/*
|
||||
* This should tell if fe_len is exactly power of 2
|
||||
*/
|
||||
|
@ -2217,7 +2219,7 @@ ext4_mb_regular_allocator(struct ext4_allocation_context *ac)
|
|||
}
|
||||
|
||||
ac->ac_groups_scanned++;
|
||||
if (cr == 0 && ac->ac_2order < sb->s_blocksize_bits+2)
|
||||
if (cr == 0)
|
||||
ext4_mb_simple_scan_group(ac, &e4b);
|
||||
else if (cr == 1 && sbi->s_stripe &&
|
||||
!(ac->ac_g_ex.fe_len % sbi->s_stripe))
|
||||
|
|
Loading…
Reference in a new issue