On Mar 12, 2009 20:38 -0400, Theodore Ts'o wrote: > On Thu, Mar 12, 2009 at 01:46:57PM -0500, Eric Sandeen wrote: > > Thiemo Nagel reported that: > > > > # dd if=/dev/zero of=image.ext4 bs=1M count=2 > > # mkfs.ext4 -v -F -b 1024 -m 0 -g 512 -G 4 -I 128 -N 1 \ > > -O large_file,dir_index,flex_bg,extent,sparse_super image.ext4 > > # mount -o loop image.ext4 mnt/ > > # dd if=/dev/zero of=mnt/file > > > > oopsed, with a BUG_ON in ext4_mb_normalize_request because > > size == EXT4_BLOCKS_PER_GROUP > > > > It appears to me (esp. after talking to Andreas) that the BUG_ON > > is bogus; a request of exactly EXT4_BLOCKS_PER_GROUP should > > be allowed, though larger sizes do indicate a problem. > > Clearly we should make this change to avoid the BUG_ON; but stupid > question, why shouldn't we allow sizes larger than > EXT4_BLOCKS_PER_GROUP? > > Especially with flex_bg, it is possible for an allocation size > > EXT4_BLOCKS_PER_GROUP to be satisifed, especially if the filesystem > isn't that full yet, and it might even make sense to request a larger > allocation for video files that are getting preallocated, for > example.... There are two reasons that we can't have too-large mballoc allocations: - mballoc works on a per-group basis, so the most blocks that it can allocate at a time is BLOCKS_PER_GROUP. - the on-disk extent format cannot map more than 128MB at a time, which is equal to the group size at 4kB blocksize. Cheers, Andreas -- Andreas Dilger Sr. Staff Engineer, Lustre Group Sun Microsystems of Canada, Inc. -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
