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. --D > > -Eric > -- > 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 -- 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
