The answer confuses me.
See ext2 source code (it is less than 9K lines, not scary at all), function ext2_block_to_path.
i_block field (meaning the block number) is defined as
long, which means signed long.
i_block is checked to be non-negative, setting limit at 2^31 blocks in file system. See the comment:
Portability note: the last comparison (check that we fit into triple
indirect block) is spelled differently, because otherwise on an
architecture with 32-bit longs and 8Kb pages we might get into trouble
if our filesystem had 8Kb blocks. We might use long long, but that would
kill us on x86. Oh, well, at least the sign propagation does not matter -
i_block would have to be negative in the very beginning, so we would not
get there at all.
What I don't understand at all is why doesn't this function define i_block as
_le32, which is __u32
unsigned 32-bit integer like in inode definition and some other places?
Now, if you're interested in what limits the sizes in this table,
- file system blocks is limited by non-negatives in
long type (2^31)
- blocks per group and inodes per group limits are determined by the block bitmap/inode bitmap. Each block/inode takes 1 bit in respective block bitmap/inode bitmap and the bitmap itself occupies a whole block. So it block is 1024 bytes, there's 1024bytes * 8bits/byte = 8K blocks per group
- bytes per block group - blocks per group * block size. For 1024-byte blocks results in 8K blocks/group * 1024 bytes/block = 8 MiB/group
- file system size (Linux) - as mentioned in comments, i_blocks field of inode, representing the total number of blocks in inode strangely operates 512-byte sectors, not real blocks.
- blocks per file - determined by 3-level indirect blocks. With 1024-byte blocks, we can squeeze 256 pointers = 2^8 pointers into each block, which results in 2^24 blocks per file = 16 Million blocks/file
- file size - multiply blocks per file by block size, which for 1024-byte blocks
results in 16 Billion byte (16 GiB) files.