# ext4 File Size Limit: Inode Boundaries, Block Sizes, and Linux Container Ceilings

The ext4 file size limit is 16 TiB under the standard 4 KiB block size, governed by 32-bit logical block addressing in the Linux kernel extent tree. While ext4 supports volume sizes up to 1 EiB, containerized workloads and AI pipelines often fail earlier due to fixed inode exhaustion and dirty buffer writeback stalls. This guide examines the extent architecture, block size mathematics, container storage limits, and persistent workspace storage patterns.

Source: https://fast.io/resources/ext4-file-size-limit/
Author: [Derek Labian](https://fast.io/authors/derek-labian/)
Last reviewed: 2026-10-11

## What is the ext4 file size limit?

The ext4 file size limit is 16 TiB when formatted with the standard 4 KiB block size, scaling up to 64 TiB with 64 KiB block sizes, governed by the 48-bit block allocation addressing in the Linux kernel. A single file cannot exceed this boundary on standard systems because the logical block index inside the ext4 extent structure is a 32-bit integer.

In production environments, Linux systems rarely fail because a single database or archive file crosses 16 TiB. Failure occurs when system operators confuse raw disk capacity with filesystem metadata boundaries. Storage volumes crash with write errors when Docker overlays exhaust fixed inode tables, or when concurrent workers downloading multi-gigabyte AI model checkpoints exhaust kernel page cache writeback buffers. Understanding ext4 limits requires separating physical block addressing from logical block indexes and inode allocation policies.

### Block size determines file and volume limits

The block size chosen when creating an ext4 filesystem defines both the maximum size of an individual file and the maximum volume size of the entire partition. On Linux, ext4 supports block sizes of `1 KiB`, `2 KiB`, `4 KiB`, and `64 KiB`. The block size must be an integral power of two and cannot exceed the memory page size of the host CPU architecture.

The following table details how block size choices dictate ext4 capacity limits across Linux architectures:

| Block Size | Max Single File Size | Max Volume Size (32-bit legacy) | Max Volume Size (64-bit modern) | Architecture Requirement |
| :--- | :--- | :--- | :--- | :--- |
| **1 KiB (1,024 bytes)** | 4 TiB | 4 TiB | 16 TiB | All architectures (x86, ARM, RISC-V) |
| **2 KiB (2,048 bytes)** | 8 TiB | 8 TiB | 32 TiB | All architectures (x86, ARM, RISC-V) |
| **4 KiB (4,096 bytes)** | 16 TiB | 16 TiB | 1 EiB (Exbibyte) | Standard Linux default across x86_64 |
| **64 KiB (65,536 bytes)** | 64 TiB to 256 TiB | 256 TiB | 1 EiB (Exbibyte) | ARM64 and PowerPC (requires 64 KiB page size) |

### The x86_64 architecture constraint

On x86_64 hardware, the Linux kernel enforces a standard memory page size (`PAGE_SIZE`) of 4,096 bytes (`4 KiB`). The Linux Virtual File System (VFS) and page cache layer require that a filesystem block size cannot exceed the kernel page size. While ext4 theoretically supports `64 KiB` block sizes, formatting an ext4 filesystem with `64 KiB` blocks on standard x86_64 Linux fails or refuses to mount.

Consequently, for almost every x86_64 production server, virtual machine, and container host, `4 KiB` is the hard ceiling for block size. That locks the practical ext4 single-file limit to exactly 16 TiB. Systems requiring files larger than 16 TiB on x86_64 must adopt filesystems designed for larger extents, such as XFS or ZFS, or distribute large datasets across object storage and managed cloud workspaces.

## How extents and 48-bit addressing govern ext4 disk layout

To understand why the 16 TiB limit exists, you have to look at how ext4 records where file data sits on a storage device. Earlier Linux filesystems like ext2 and ext3 used indirect block mapping. Under ext3, an inode stored pointers to individual data blocks. When files grew large, the filesystem created indirect, doubly indirect, and triply indirect block pointer tables. This mechanism produced severe disk fragmentation and created huge metadata overhead when reading large contiguous datasets.

Ext4 eliminated indirect block pointers for files, replacing them with an extent tree.

### The anatomy of an ext4 extent

An extent represents a single contiguous run of physical disk blocks allocated to a file. Instead of recording 10,000 individual block numbers for a 40 MB video file, ext4 records a single extent entry that states the starting logical block, the starting physical block, and the length of the run.

In the Linux kernel source code, each extent is represented by the 12-byte `struct ext4_extent`:

```c
struct ext4_extent {
    __le32 ee_block;    /* first logical block extent covers */
    __le16 ee_len;      /* number of blocks covered by extent */
    __le16 ee_start_hi; /* high 16 bits of physical block */
    __le32 ee_start_lo; /* low 32 bits of physical block */
};
```

The fields inside this structure explain the dual limits of ext4:

- **32-bit logical block limit (`ee_block`):** The logical offset within the file is tracked by a 32-bit integer (`__le32`). This restricts any single file to an index of at most 2^32 logical blocks. When multiplied by the standard `4 KiB` block size (4,096 bytes), the absolute maximum offset reachable within a file is 2^32 * 4,096 = 17,592,186,044,416 bytes, which equals 16 TiB.
- **48-bit physical block limit (`ee_start_hi` and `ee_start_lo`):** The physical block location on disk is split into a 16-bit high field and a 32-bit low field, creating a 48-bit block address. With `4 KiB` blocks, 2^48 addressable blocks yield 2^60 bytes, establishing the 1 EiB (`1,048,576 TiB`) theoretical volume limit.
- **Maximum extent length (`ee_len`):** Because the length field is a `16-bit` integer, a single extent can map a maximum of `32,768` blocks (blocks above 32,768 use the high bit to mark unwritten preallocated extents). When formatted with standard `4 KiB` blocks, one extent maps `128 MiB` of contiguous physical data.

### Inode structures and the HTree index

Every file in ext4 corresponds to an on-disk inode. The ext4 inode structure reserves 60 bytes in its `i_block` field. An extent header occupies 12 bytes, leaving 48 bytes for extent entries. Because each `struct ext4_extent` consumes 12 bytes, up to four extents can reside directly inside the file's inode.

When a file is fragmented across more than four extents, the root node in the inode transforms into an index node (`struct ext4_extent_idx`), pointing to external extent tree leaf blocks. This tree structure allows ext4 to scale to millions of blocks per file without performance degradation.

Ext4 also solved the directory scaling bottleneck of ext3. Ext3 limited directories to 32,000 subdirectories because directory links used a 16-bit counter. Ext4 introduced `dir_index` using a specialized constant-depth B-tree known as an HTree. Using 32-bit hashes of filenames, an ext4 directory with `4 KiB` blocks can store tens of millions of files efficiently. When formatted with the `large_dir` feature in modern kernels, ext4 supports billions of files in a single directory.

## The inode boundary: why df -h hides filesystem failure

While single-file size limits receive widespread attention, the most frequent point of failure on ext4 is inode exhaustion. Unlike copy-on-write filesystems like Btrfs or ZFS that allocate file identifiers dynamically, ext4 creates a static inode table at the time the partition is formatted.

Every file, directory, named pipe, and symbolic link created on an ext4 filesystem requires exactly one inode. Once all inodes are consumed, the filesystem cannot create new files, even if hundreds of gigabytes of disk space remain unallocated.

### The difference between df -h and df -i

When monitoring disk space, engineers routinely run `df -h` to inspect storage consumption. A server running an AI training pipeline or a web crawler might display:

```bash
$ df -h /data
Filesystem      Size  Used Avail Mounted on
/dev/nvme0n1p1  2.0T  320G  1.6T /data
```

Seeing 1.6 TiB available suggests plenty of headroom. Yet an application attempting to write a new checkpoint or log file fails immediately with the operating system error:

```
IOError: Errno 28, No space left on device
```

Running `df -i` reveals the root cause:

```bash
$ df -i /data
Filesystem        Inodes     IUsed IFree Mounted on
/dev/nvme0n1p1 131072000 131072000     0 /data
```

The volume has exhausted all available inodes, leaving zero free index nodes. Because the operating system cannot allocate an inode for the incoming file, the kernel returns `ENOSPC`, the exact same error code emitted when storage blocks run out.

### Calculating inode ratios during formatting

When `mkfs.ext4` creates a filesystem, it calculates the number of inodes by dividing the total partition size by the inode ratio parameter (`-i` bytes-per-inode). The default configuration in `/etc/mke2fs.conf` typically allocates one inode for every 16,384 bytes (`16 KiB`) of disk space.

If your workload consists of large files (such as database files, high-resolution videos, or large machine learning weights), a `16 KiB` inode ratio wastes disk space on unused inode tables. An inode table consumes `256 bytes` per inode, which allocates substantial disk capacity to metadata structures before user data lands on the drive.

Conversely, if your workload generates millions of small files (such as tokenized dataset shards, Python virtual environments, Git repositories, or web scraper caches), the average file size drops below `4 KiB`. In this scenario, inodes deplete three to four times faster than block storage.

To inspect the inode allocation and block geometry of an existing ext4 filesystem, run `dumpe2fs`:

```bash
sudo dumpe2fs -h /dev/nvme0n1p1 | grep -E "Inode count|Block count|Inode size|Block size"
```

To create an ext4 filesystem tailored for small-file density, allocate one inode per 4 KiB block to maximize total file count:

```bash
sudo mkfs.ext4 -i 4096 -b 4096 /dev/nvme0n1p1
```

Alternatively, specify an exact inode count directly:

```bash
sudo mkfs.ext4 -N 250000000 /dev/nvme0n1p1
```

The inode count cannot be expanded after formatting without backing up the data and recreating the filesystem.

## Linux container ceilings: Docker overlays and AI model weight stalls

In containerized environments, ext4 storage limits interact with Linux container runtimes in unexpected ways. Docker and Kubernetes deployments running on top of ext4 hosts use the `overlay2` storage driver. This architecture creates two distinct friction points: inode multiplication and page cache writeback stalls.

### How Docker overlay2 accelerates inode depletion

The `overlay2` storage driver constructs a unified filesystem view by stacking multiple directory layers: lower directories (read-only image layers) and an upper directory (the container's read-write layer). When an application inside a container touches a file from a lower image layer, the container runtime uses a copy-up operation to replicate that file into the upper layer.

Every image build step, intermediate layer, and container instance allocates inodes from the host's underlying ext4 filesystem. A Dockerfile that installs system packages, compiles source code, and leaves build artifacts across intermediate layers can burn hundreds of thousands of host inodes.

When multiple containers run in parallel, background tasks like logging, cache generation, and package updates consume inodes from the shared root ext4 partition. If the host partition was formatted with a standard `16 KiB` inode ratio, a Kubernetes node can exhaust inodes while hosting low disk volumes, terminating pods across the entire node.

### AI model weights and memory writeback thrashing

Modern machine learning workloads frequently mount model weights formatted in `.safetensors`, GGUF, or PyTorch checkpoints. A single model checkpoint file frequently measures tens of gigabytes. While these files are far below the 16 TiB ext4 file limit, writing or checkpointing them inside ext4 container volumes exposes serious buffer bottlenecks.

Linux uses the page cache to buffer dirty writes before flushing them to physical storage. The kernel controls this behavior with two sysctl parameters:

- `vm.dirty_background_ratio`: The percentage of system memory that can hold dirty pages before background kernel threads begin writing blocks to disk.
- `vm.dirty_ratio`: The hard maximum percentage of system memory that can hold dirty pages before user processes writing data are forced to block and perform synchronous I/O.

When a containerized training run writes a `40 GB` checkpoint file to an ext4 volume on a machine with `128 GB` of RAM, dirty pages rapidly flood system memory. Once `vm.dirty_ratio` is crossed, the writing process stalls, and other containers sharing the host experience extreme I/O wait times. If ext4 journaling is operating in `data=ordered` mode, metadata updates queue behind massive contiguous block allocations, creating latency spikes that trigger health check timeouts in container orchestrators.

To inspect current Linux kernel dirty writeback thresholds, run:

```bash
sysctl vm.dirty_background_ratio vm.dirty_ratio
```

To lower dirty writeback thresholds for high-throughput ext4 write workloads, force the kernel to flush data earlier:

```bash
sudo sysctl -w vm.dirty_background_ratio=5
sudo sysctl -w vm.dirty_ratio=10
```

Lowering dirty writeback thresholds forces the kernel to flush data to disk earlier and in smaller bursts, preventing large model checkpoints from choking the ext4 write pipeline.

## Managing large files and AI datasets in persistent cloud workspaces

As engineering teams build distributed AI systems, relying entirely on local ext4 disks creates maintenance friction. Local storage binds data to specific virtual machines, requires constant monitoring of inode tables, and forces developers to manage complex volume mounts across container boundaries.

Teams building data-intensive pipelines and multi-agent systems benefit from decoupling compute instances from persistent file storage. Instead of storing large datasets, model weights, and research archives directly on ephemeral container filesystems, organizations use persistent cloud workspaces.

### Transitioning from local disks to intelligent workspaces

Traditional object stores and commodity cloud drives were designed for human file sharing or cold archival. They lack the real-time collaboration features and contextual intelligence required by autonomous agent workflows.

Modern cloud platforms like [Fastio Workspaces](/product/workspaces/) provide intelligent storage infrastructure tailored for engineering teams and AI agents:

- **High-capacity chunked uploads:** Upload large datasets, media archives, and model checkpoints reliably without hitting web server buffer limits or client-side connection drops.
- **Intelligence Mode and semantic search:** Enabling Intelligence on a workspace auto-indexes files on arrival. AI agents can perform hybrid searches (combining full-text keyword matching and semantic meaning) to retrieve specific passages from documentation or research sets with exact citations, rather than loading multi-gigabyte corpora into prompt context. Explore how teams implement this on [Fastio AI](/product/ai/).
- **Remote Model Context Protocol (MCP) server:** Autonomous agents interact with workspace files through native Streamable HTTP endpoints. Coding agents connect via `https://mcp.fast.io/mcp/code`, Claude desktop and general applications connect via `https://mcp.fast.io/mcp/tools`, and ChatGPT or Codex users connect through the Fastio plugin or `https://mcp.fast.io/mcp/operations`. For detailed integration patterns, see [Storage for AI Agents](/storage-for-agents/).
- **Collaborative Notes and version tracking:** Human engineers and AI agents can write shared notes and project documentation next to workspace files. Every file retains comprehensive version history, preventing concurrent writes from destroying historical data.
- **Advisory file locks:** When multiple agents access the same file, agents acquire advisory leases using `lock-acquire` and release them with `lock-release` through the `storage_manage` MCP tool, keeping multi-agent pipelines coordinated.
- **Audit trails and access control:** Workspace administrators govern file access through granular permissions across organizations, workspaces, and shares. A detailed activity log records changes made by humans and automated agents.

### Flexible subscriptions for scalable storage

Fastio offers three organization plans:

- **Starter:** Includes 3 member seats, `250 GB` storage, 5 workspaces, and 100,000 monthly AI credits for `$9.99` per month. Maximum upload size is `25 GB`.
- **Business:** Includes 10 member seats, `5 TB` storage, 50 workspaces, and 600,000 monthly AI credits for `$49.99` per month. Maximum upload size is `50 GB`.
- **Enterprise:** Includes 30 member seats (extra seats `$1` a month each, up to 200), `25 TB` storage, 200 workspaces, and 3,000,000 monthly AI credits for `$199.99` per month. Maximum upload size is `100 GB`.

Monthly subscriptions begin with a 14-day free trial that requires a credit card. Teams can connect autonomous agents, store project files, and query document collections without managing ext4 block allocations or monitoring local inode boundaries.

## Frequently asked questions

### What is the maximum file size in ext4?

The maximum single-file size in ext4 is 16 TiB when using the standard 4 KiB block size. On architectures that support 64 KiB memory page sizes (such as ARM64 or PowerPC), ext4 can scale to a 64 TiB single-file limit, with theoretical limits reaching up to 256 TiB.

### What is the difference between ext4 and ext3 file limits?

Ext3 enforces a 2 TiB single-file limit and a 16 TiB volume limit using indirect block mapping. Ext4 raises the single-file limit to 16 TiB and the volume limit to 1 EiB by implementing 48-bit physical block addressing and an extent tree. Ext4 also replaces the 32,000 subdirectory ceiling with unlimited subdirectories using HTree indexing.

### How do block sizes change the ext4 file limit?

Because ext4 tracks logical file offsets using a 32-bit block index, the maximum file size equals 2^32 multiplied by the block size. A 1 KiB block yields a 4 TiB file limit, a 2 KiB block yields an 8 TiB limit, a 4 KiB block yields a 16 TiB limit, and a 64 KiB block allows files up to 256 TiB.

### Can an ext4 filesystem support files larger than 16 TiB?

On standard x86_64 Linux systems, an ext4 filesystem cannot exceed a 16 TiB single-file limit because the kernel restricts the block size to the 4 KiB CPU page size. Files larger than 16 TiB require either an architecture supporting 64 KiB page sizes (like ARM64) or an alternative filesystem such as XFS or ZFS.

### Why do I get a No space left on device error when df -h shows free space?

An ext4 filesystem produces a No space left on device error (ENOSPC) when it runs out of inodes, even if raw disk blocks are available. You can verify this by running df -i. If inode utilization reaches full capacity, the filesystem cannot allocate new files until existing files are deleted.

### How do Docker containers cause ext4 inode exhaustion?

Docker uses the overlay2 storage driver, which replicates modified files across container layers using copy-up actions. Storing thousands of small dependencies, build caches, and intermediate layers across multiple containers quickly exhausts the static inode table on the host ext4 volume.

### Can an x86_64 Linux system use a 64 KiB block size on ext4?

Standard x86_64 Linux kernels do not support a 64 KiB block size on ext4 because the Linux Virtual File System requires the block size to be less than or equal to the CPU memory page size, which is fixed at 4 KiB on x86_64.

### How should engineering teams store massive datasets and AI model weights?

Teams managing large datasets and AI model checkpoints should decouple local container compute from storage. Storing files in persistent cloud workspaces like Fastio allows teams to handle large chunked uploads, auto-index documents for RAG, and connect AI agents via MCP without running into local disk buffer limits.

## Sources

- [Wikipedia: Ext4](https://en.wikipedia.org/wiki/Ext4): The ext4 filesystem supports single files up to 16 TiB with a 4 KiB block size and has a practical volume limit of 1 EiB.

## About Fast.io

Fast.io provides shared workspaces where people and AI agents work on the same files, with built-in semantic search and citation-backed chat over what they hold. Agents reach it through a remote MCP server, a REST API at https://api.fast.io/current/, and a command line client published on npm as @vividengine/fastio-cli. MCP setup is at https://mcp.fast.io/docs: Claude and most MCP clients connect to https://mcp.fast.io/mcp/tools, ChatGPT to https://mcp.fast.io/mcp/operations, and coding agents to https://mcp.fast.io/mcp/code.