为何bytes-per-inode最大比值为67108864？该上限的依据是什么？

Great question—this is one of those filesystem implementation details that feels arbitrary until you dig into the constraints under the hood. Let’s break this down specifically for the ext2/ext3/ext4 filesystems (since this 64MB limit is unique to them):

The Core Constraint: Block Group Structure #

Ext filesystems organize storage into fixed-size chunks called block groups. By default, each block group is 64MB (67108864 bytes) in size—this is a hard limit baked into the filesystem’s metadata design (the fields tracking block group boundaries use 16-bit counters, which cap the number of blocks per group at 65536; multiply that by the maximum 4KB block size, and you get 64MB).

Each block group requires its own inode table, and the filesystem enforces that every block group must have at least one inode allocated to it. This isn’t about your files—it’s about keeping the filesystem’s metadata structure consistent and usable.

How This Translates to the Bytes-Per-Inode Limit #

When you set a bytes-per-inode value, mkfs calculates the total number of inodes as:

total_inodes = total_disk_size / bytes_per_inode

To ensure every block group gets at least one inode, the total number of inodes must be at least equal to the number of block groups. Let’s do the math:

• Number of block groups = total_disk_size / 64MB
• So total_inodes ≥ total_disk_size / 64MB
• Rearranged: bytes_per_inode ≤ 64MB

If you tried to set a bytes-per-inode larger than 64MB, the total number of inodes would be less than the number of block groups—leaving some block groups without any inodes. This would break the filesystem’s metadata layout, so mkfs enforces 67108864 as the hard upper limit.

Why mkfs Doesn’t Care About Your File Sizes #

You’re right that mkfs has no idea what files you’ll store later—but this limit isn’t about optimizing for your use case. It’s about ensuring the filesystem can exist at all. The block group and inode table structure is set during formatting, and it has to be valid regardless of what you put on the disk later. Even if you only store huge video files, the filesystem needs a consistent metadata framework to track them, and that requires every block group to have at least one inode reserved.

A Quick Side Note #

This limit is specific to ext filesystems. Other filesystems like XFS or Btrfs use different inode allocation models (e.g., dynamic inode creation) and don’t have this 64MB upper bound on bytes-per-inode.

内容的提问来源于stack exchange，提问作者OJFord