Understanding mke2fs Block Size Options in Linux

The mke2fs command is a fundamental Linux administration utility used to create ext2, ext3, and ext4 filesystems. Customizing the filesystem block size using the -b option in mke2fs is a critical optimization step that directly impacts disk space utilization, I/O throughput, maximum file size limitations, and system memory overhead. Choosing the correct block size allows system administrators to tailor storage performance specifically to the types of workloads and file distributions a system will handle.

How to Set Block Size in mke2fs

By default, mke2fs configures a filesystem with a 4096-byte (4 KiB) block size on most modern Linux architectures. To define a custom block size, administrators use the -b flag followed by the desired size in bytes:

sudo mke2fs -t ext4 -b 1024 /dev/sdb1

Supported block sizes typically range from 1024 to 4096 bytes on standard x86 systems (1024, 2048, and 4096), though architectures with larger memory page sizes (such as ARM64 or Itanium) can support larger blocks up to 64 KiB.

Storage Efficiency and Internal Fragmentation

The primary reason to adjust block size downward (e.g., to 1024 bytes) is to minimize internal fragmentation. Storage space on an ext-based filesystem is allocated in discrete block units. Even if a file contains only 100 bytes of data, the filesystem must allocate an entire block to store it.

• Small Files: On a standard 4 KiB filesystem, thousands of sub-kilobyte files (such as source code trees, maildir spools, or small configuration files) result in significant "slack space"—wasted capacity at the end of each block. Setting a 1024-byte block size reduces this waste by up to 75% for small-file-heavy applications.
• Large Files: For environments storing predominantly large files (such as database dumps, disk images, or video files), slack space becomes negligible, rendering small block sizes unnecessary.

I/O Throughput and Metadata Overhead

Block size choices directly influence read and write performance:

• Fewer I/O Operations: Larger block sizes (4096 bytes or larger) allow the operating system to transfer more data per I/O transaction. Storing a 100 MB file with 4 KiB blocks requires a quarter of the block pointer references compared to 1 KiB blocks.
• Reduced Metadata Footprint: Fewer total blocks mean smaller allocation bitmaps, fewer extent tree levels in ext4, and less CPU overhead required for the kernel to look up block addresses. This enhances sequential throughput across heavy write workloads.

System Page Size Alignment

Linux manages virtual memory in pages, which are 4096 bytes on standard x86 architectures. When the filesystem block size matches the system page size:

• Page cache operations map 1:1 with filesystem blocks.
• The kernel avoids partial-page reads and writes, reducing CPU cycles spent on translation and buffer management.
• Setting a block size smaller than the page size (e.g., 1024 or 2048 bytes) requires the kernel to manage multiple blocks per page, slightly increasing CPU and memory tracking overhead.

Impact on File and Filesystem Limits

The block size defined during mke2fs execution hardens the maximum allowable individual file size and filesystem capacity. For example, in an ext3/ext4 architecture:

• 1024-byte block size: Restricts maximum file size to approximately 16 GiB and limits total volume size to roughly 2 TiB.
• 4096-byte block size: Expands maximum single file limits to 16 TiB (ext4) and total filesystem volume size to 1 EiB.

Selecting an inappropriately small block size can unintentionally restrict future storage expansion on that partition.

Summary of Usage Recommendations

• Use 1024 or 2048 bytes: Specific partitions dedicated strictly to high volumes of small files (e.g., /var/spool/mail, custom cache partitions) where storage capacity preservation outweighs peak I/O performance.
• Use 4096 bytes: General-purpose workloads, root (/) partitions, and systems handling large or heterogeneous files, preserving 1:1 memory page alignment and maximum volume limits.