1

When I create an ext4 file system on a sparse 16GB file without reserving root space, the actual free size is 15.58GB. Why does this happen? Commands I use:

fallocate -l 16G test.img
mkfs -t ext4 -m 0 test.img
mount test.img test

In tune2fs there is a value Overhead clusters: 109857 that can be multiplied by 4096 (block size) and divided by 1024^3 to get the value in gigabytes, then get the missing ~0.41 GB. https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout says something very strange about Overhead clusters:

Overhead blocks/clusters in fs. (Huh? This field is always zero, which means that the kernel calculates it dynamically.)

What is the meaning of this? Does it have something to do with this issue? What size should I set in fallocate so that the total size of the mounted image would be 16 GB?

0

2 Answers 2

0

"overhead clusters" is all the metadata used by the filesystem to manage your disk. Typically the largest components for ext4 are the inode table and journal; you can see their sizes using tune2fs.

Default inode_ratio is 16KiB; that would give 1M inodes in your example times 256 bytes is 0.25 out of your mystery 0.41GiB.

You can set the number of inodes and journal size when the filesystem is created. As the previous commenter noted, you cannot set them to zero.

-1

What size should I set in fallocate so that the total size of the mounted image would be 16 GB?

16 GB, as you're currently doing.

When I create an ext4 file system on a sparse 16GB file without reserving root space, the actual free size is 15.58GB. Why does this happen?

Size of the device on which you store files is never the same as the space you have for files – the whole file system information (file names, properties, and where the data that belongs to a file is actually stored on the block device) needs to go somewhere!

Does it have something to do with this issue?

That's not an issue! That's just reality.

The truth is, unless you have a single file that should have exactly 16 GB size, you can't calculate the "overhead" you need: each file needs some extra space – in classic file systems, small files / file tails couldn't even be combined in a single block, so that you'd always have to round up each file size to the next multiple of block size (e.g. 4 kB).

So, this question is kind of moot. If you want to have 16 GB in storage (for what do you need exactly 16 GB of file storage? Wouldn't it be more realistic to use a 16 GB image?), you'll need to overprovision "somewhat", and that's about as exact as it gets without knowing your future file system's contents exactly down to the byte. So, 17 GB, maybe?

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .