Formatting a disk for purely large video files, I calculated what I thought was an appropriate bytes-per-inode value, in order to maximise usable disk space.

I was greeted, however, with:

mkfs.ext4: invalid inode ratio [RATIO] (min 1024/max 67108864)

I assume the minimum is derived from what could even theoretically be used - no point having more inodes than could ever be utilised.

But where does the maximum come from? mkfs doesn't know the size of files I'll put on the filesystem it creates - so unless it was to be {disk size} - {1 inode size} I don't understand why we have a maximum at all, much less one as low as 67MB.

  • Inode size is not filesize. The inode stores file metadata.
    – jordanm
    Feb 4, 2018 at 1:49
  • @jordanm I know. If the average file size is well above 67MB, (for sake of example, 6.7GB) I don't see why we need an inode for every 67MB. It seems an arbitrary cap on the ratio to me, I'm trying to understand the reason for it.
    – OJFord
    Feb 4, 2018 at 2:59

2 Answers 2


Because of the way the filesystem is built. It's a bit messy, and by default, you can't even have the ratio as down as 1/64 MB.

From the Ext4 Disk Layout document on kernel.org, we see that the file system internals are tied to the block size (4 kB by default), which controls both the size of a block group, and the amount of inodes in a block group. A block group has a one-block sized bitmap of the blocks in the group, and a minimum of one block of inodes.

Because of the bitmap, the maximum block group size is 8 blocks * block size in bytes, so on an FS with 4 kB blocks, the block groups are 32768 blocks or 128 MB in size. The inodes take one block at minimum, so for 4 kB blocks, you get at least (4096 B/block) / (256 B/inode) = 16 inodes/block or 16 inodes per 128 MB, or 1 inode per 8 MB.

At 256 B/inode, that's 256 B / 8 MB, or 1 byte per 32 kB, or about 0,003 % of the total size, for the inodes.

Decreasing the number of inodes would not help, you'd just get a partially-filled inode block. Also, the size of an inode doesn't really matter either, since the allocation is done by block. It's the block group size that's the real limit for the metadata.

Increasing the block size would help, and in theory, the maximum block group size increases in the square of the block size (except that it seems to cap at a bit less than 64k blocks/group). But you can't use a block size greater than the page size of the system, so on x86, you're stuck with 4 kB blocks.

However, there's the bigalloc feature that's exactly what you want:

for a filesystem of mostly huge files, it is desirable to be able to allocate disk blocks in units of multiple blocks to reduce both fragmentation and metadata overhead. The bigalloc feature provides exactly this ability.

The administrator can set a block cluster size at mkfs time (which is stored in the s_log_cluster_size field in the superblock); from then on, the block bitmaps track clusters, not individual blocks. This means that block groups can be several gigabytes in size (instead of just 128MiB); however, the minimum allocation unit becomes a cluster, not a block, even for directories.

You can enable that with mkfs.ext4 -Obigalloc, and set the cluster size with -C<bytes>, but mkfs does note that:

Warning: the bigalloc feature is still under development
See https://ext4.wiki.kernel.org/index.php/Bigalloc for more information

There are mentions of issues in combination with delayed allocation on that page and the ext4 man page, and the words "huge risk" also appear on the Bigalloc wiki page.

None of that has anything to do with that 64 MB / inode limit set by the -i option. It appears to just be an arbitrary limit set at the interface level. The number of inodes can also be set directly with the -N option, and when that's used, there are no checks. Also, the upper limit is based on the maximum block size of the file system, not the block size actually chosen as the structural limits are.

Because of the 64k blocks/group limit, without bigalloc there's no way to get as few inodes as the ratio of 64 MB / inode would imply, and with bigalloc, the number of inodes can be set much lower than it.


The number you see are hardcoded, for the reasons below.

The mke2fs source code has:

            com_err(program_name, 0,
                _("invalid inode ratio %s (min %d/max %d)"),
                optarg, EXT2_MIN_BLOCK_SIZE,
                EXT2_MAX_BLOCK_SIZE * 1024);

(there is even a message in the release notes about being nicer to user and showing the minimum and maximum value possible when an error is thrown, which is better than before).

And also:


And finally:

define EXT2_MIN_BLOCK_LOG_SIZE      10  /* 1024 */
define EXT2_MAX_BLOCK_LOG_SIZE      16  /* 65536 */

So that explains what you see.

I would have expected myself, per https://unix.stackexchange.com/a/193140/211833, that the ratio would be at most the maximum partition size divided by the maximum inode count, but it is not.

Per its specifications, for ext4 the maximum volume size is 1 exbibyte (260 bytes), the maximum number of inodes is 232, and the maximum file size is 16 TiB (16 * 240 = 244) for 4k blocks.

So the maximum partition size divided by the inode count would be 260-32 = 228, which is not what is hardcoded in the source file (67108864 is 226). I have no idea for the difference, but I am not a filesystem developer either.

  • Ah you might be on to it if you meant minimum inside count? I was assuming it would be acceptable to have one, for a single file that might fill the disk.
    – OJFord
    Feb 4, 2018 at 10:20

You must log in to answer this question.

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