aboutsummaryrefslogtreecommitdiff
path: root/fs/ext4/super.c
diff options
context:
space:
mode:
authorGravatar Jan Kara <jack@suse.cz> 2017-02-10 00:50:56 -0500
committerGravatar Theodore Ts'o <tytso@mit.edu> 2017-02-10 00:50:56 -0500
commitd9b22cf9f5466a057f2a4f1e642b469fa9d73117 (patch)
tree61fb0bf8028df1bd79ea44c4376b213dcd70249a /fs/ext4/super.c
parentdax: assert that i_rwsem is held exclusive for writes (diff)
downloadlinux-d9b22cf9f5466a057f2a4f1e642b469fa9d73117.tar.gz
linux-d9b22cf9f5466a057f2a4f1e642b469fa9d73117.tar.bz2
linux-d9b22cf9f5466a057f2a4f1e642b469fa9d73117.zip
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>
Diffstat (limited to 'fs/ext4/super.c')
0 files changed, 0 insertions, 0 deletions