On 10/10/11 3:11 PM, Darrick J. Wong wrote: > On Mon, Oct 10, 2011 at 01:43:28PM -0500, Eric Sandeen wrote: >> On 10/10/11 10:50 AM, Eric Sandeen wrote: >>> When looking at the maximal filesystem size issue, I found myself >>> wondering what the "- 8" is in here, it's not commented >>> or documented anywhere: >>> >>> #define EXT2_MAX_BLOCKS_PER_GROUP(s) (((1 << 16) - 8) * \ >>> (EXT2_CLUSTER_SIZE(s) / \ >>> EXT2_BLOCK_SIZE(s))) >>> >>> >>> (pre-bigalloc, it was just ((1 << 16) - 8) ) >>> >>> Anyone know? >> >> Ah, Darrick pointed out >> >> http://osdir.com/ml/file-systems.ext2.devel/2006-03/msg00032.html >> >> So it would have been - 1, to not overflow __u16, but since we have >> multiples of 8, we get - 8. >> >> But now we have bg_free_blocks_count_hi, giving us 32 bits of counter. >> With EXT4_FEATURE_INCOMPAT_64BIT, MAX_BLOCKS_PER_GROUP should grow, no? > > As far as I know, each group contains a block bitmap that is exactly 1 block > long, and block can be no longer than 4096 bytes in length. Therefore, a group > can have no more than 4096 * 8 = 32768 blocks, correct? To get more we'd have > to allow blocks larger than 4K (mkfs won't allow that) or change the disk > format to allow multi-block block bitmaps. > > Unless of course a block bitmap can be the size of a cluster.... which afaict > is not the case. You are right: if (fs_param.s_blocks_per_group) { if (fs_param.s_blocks_per_group < 256 || fs_param.s_blocks_per_group > 8 * (unsigned) blocksize) { com_err(program_name, 0, _("blocks per group count out of range")); So I guess 64k blocks on ia64 or ppc64 would get us up to 512k blocks per group. but then MAX_BLOCKS_PER_GROUP limits us to less than that, at least for now. So still not sure what bg_free_blocks_count_hi does for us. -Eric > --D -- 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
