U-Boot ext4 Writes: Separate Filesystem Metadata Resources from File Length

A tiny file can fail to write from U-Boot even when the same image
can be listed and read. The payload length is only one part of the write
path’s memory demand. In U-Boot v2025.01, write initialization allocates
metadata structures across the filesystem’s block groups before it
reaches the file-specific allocation calculation.

This matters when a product moves from a small test filesystem to a
larger production layout while keeping the same bootloader heap. The
correct comparison is between filesystem geometry and write-path
allocations, not just between the old and new file sizes.

Confirm that the
build includes the writer

The tagged
ext4 guide distinguishes read-only filesystem support from write
support. CONFIG_CMD_EXT4_WRITE selects the ext4 writer;
enabling generic filesystem commands alone does not enable ext4
support.

A working load command therefore establishes neither that the writer
was included nor that its resource requirements are satisfied. Check the
actual configuration and available command before interpreting an
allocation failure. Once the writer exists, retain the filesystem’s
block size, total blocks, first data block, blocks per group and
descriptor size alongside the bootloader build identity.

Count the two bitmap
families

In ext4fs_init,
the implementation calculates the number of block groups by rounding up
the relevant filesystem block count divided by blocks per group. It then
allocates a pointer array for block bitmaps and one full filesystem
block of storage for every group.

It repeats that pattern for inode bitmaps: another pointer array and
another full block per group. Both families are retained for the write
operation. The code reads their contents from the filesystem; this is
not a demand-loaded cache limited to the groups touched by the new
file.

For a successfully initialized filesystem with G groups and block
size B, these two bitmap-buffer families alone require
2 × G × B bytes. For example, 64 groups with 4096-byte
blocks account for 524288 bytes, or 512 KiB, before their pointer arrays
and other allocations. That is arithmetic from the allocation loops, not
a measured heap high-water mark.

The number of groups is the useful variable. Disk capacity by itself
is insufficient because formatting choices change blocks per group and
block size. A smaller payload does not reduce these two loops.

Add descriptors
and journal state to the budget

The same source allocates the group descriptor table after rounding
its size up to a filesystem-block boundary. That allocation depends on
group count and descriptor size. It also allocates the superblock and
file-operation structures, so the bitmap subtotal cannot be used as the
complete heap requirement.

The separate journal
implementation adds more state. Initialization allocates journal-log
and dirty-block bookkeeping entries; block-sized buffers are also
allocated for journal contents and later metadata tracking. Journal
processing includes checking and potentially recovering journal
state.

Accordingly, an attempted write is not a read-only memory probe. Use
preserved, disposable filesystem images for instrumentation. Do not
discover a product’s heap limit by repeatedly attempting writes against
its only bootable filesystem.

Distinguish
resource failure from write admission

The writer also checks supported filesystem feature masks and rejects
a hash-indexed parent directory in this version. Those are different
failure causes from insufficient memory. Listing a directory
successfully does not establish that the write path accepts every
feature of that directory or filesystem.

A useful qualification matrix keeps the file small and fixed while
varying approved filesystem geometry. Instrument allocation requests and
failures in the exact bootloader build, and record the first failing
stage. Separately check feature-admission diagnostics so that a format
incompatibility is not misreported as a heap shortage.

Then repeat with the largest intended payload and realistic
surrounding boot activity to establish the product’s actual peak memory
use. This article supplies no measured heap requirement, universal
minimum or successful write result. The actionable finding is narrower:
budget the whole-filesystem metadata allocations before treating file
length as the controlling resource.