Hi folks, I've been looking at getting around some of the limitations imposed by the block groups and was wondering what are peoples thoughts about implementing this using either bigger block groups or storing the bitmaps and inode tables outside of the block groups. I think the BIG_BG feature is better suited to the design philosophy of ext2/3. Since all the important meta-data is easily accessible thanks to the static filesystem layout, I would expect for easier fsck recovery. This should also provide with some performance improvements for both extents (allowing each extent to be larger than 128M) as well as fsck since bitmaps would be place closer together. An extended version of metadata block group could provide better performance improvements during fsck time since we could pack all of the filesystem bitmaps together. Having the inode tables separated from the block groups could mean that we could implement dynamic inodes in the future as well. This feature seems like it would be more invasive for e2fspros at first glance (at least for fsck). Also, with no metadata in the block groups, there is essentially no need to have a concept of block groups anymore which would mean that this is a completely different filesystem layout compared to ext2/3. Since I have not much experience with ext4 development, I was wondering if anybody had any opinion as to which of these two methods would better serve the need of the intended users and see which one would be worth to prototype first. Comments? -JRS - 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
