Theodore Tso wrote:
So what's the current limitation on the maximum size of the filesystem
without big block groups? Well, the block group number is an unsigned
32 bit number, so we can have 2**32 block group. Using a 4k (2**12)
block group, have a limit of 32768 blocks per block group, or 2**15
blocks. So the limit is 2**(32+15) or 2**47 blocks, or 2**59 bytes
(512 petabytes).
Hi Ted,
thanks for your comments.
In fact, there is another limitation related to the block group size:
all the group descriptors are stored in the first group of the filesystem.
Currently, with a 4-KB block size, the maximum size of a group is
2**15 blocks = 2**27 bytes.
With a group descriptor size of 32 bytes, we can store a maximum of
2**32 / 32 = 2**22 group descriptors in the first group.
So the maximum number of groups is limited to 2**22 which limits the
size of the filesystem to
2**22(groups) * 2**15(blocks) * 2**12(blocksize) = 2**49 bytes = 512TB
With big block groups, we can grow beyond this limit of 512TB.
Based on this analysis, it's clear that the big block groups patch has
some benefits, but I'm wondering if they are sufficiently large to be
worth it, especially since we also have to consider the changes
necessary to the e2fsprogs (which haven't been written yet as far as I
know).
I already made changes in the e2fsprogs to support larger block groups,
but there is still some work to do.
The first thing is when creating a large filesystem (over 512TB or
perhaps before) which is the optimal value for the block group size ?
How to set its default value used by mkfs ?
It is why I do tests now to see the behavior of a system when increasing
the size of the block groups.
Valérie
-
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
