On 6/9/2011 8:08 PM, Andreas Dilger wrote:
There is only a single block pointer for each bitmap per group. That said,
with flex_bg this is mostly meaningless, since the bitmaps do not have to
be located in the group, and a flex group is the same as a virtual group
that is {flex_bg_factor} times as large.
Of course there is only a single pointer because there is only a single
bitmap. What does this have to do with limiting the block count to 8 *
blocksize?
3) Why does 64bit disable the resize inode?
Because the on-disk format of the resize inode is only suitable for 32-bit
filesystems (it is an indirect-block mapped file and cannot reserve blocks
beyond 2^32). The "future" way to resize filesystems is using the META_BG
feature, but the ability to use it has not been integrated into the kernel
or e2fsprogs yet.
Ahh, right... no indirect blocks. Couldn't and shouldn't the resize
inode just use extents instead? Also I thought that META_BG was an idea
that eventually become FLEX_BG and has been dropped?
--
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
