Skip to content

fsforge v0.2.0

Latest

Choose a tag to compare

@emmanuel-deloget emmanuel-deloget released this 26 Jul 15:23
· 4 commits to main since this release
v0.2.0
f8a1217

fsforge v0.2.0

Large-file support in the ext engines, plus the allocator work it needed.

alloc: an allocation is no longer required to fit in a single contiguous
run. AllocRuns chains as many runs as a request needs — the whole remainder
when it fits, otherwise the largest run available — and rolls back entirely
on failure. Handing out a partial run is the new optional RunAllocator
capability (AllocUpTo); a plain Allocator is probed by halving instead, so
an injected policy keeps working unchanged. Bitmap now scans 64 bits at a
time from a free hint rather than bit by bit from block 0, which took layout
from quadratic to near-linear in block count; first-fit stays exact, so
layouts are byte-identical to v0.1.1.

ext: files, directories and long symlink targets are laid out across several
runs. Every block group opens with its own metadata, so no free run can span
more than one group — 128 MiB at 4 KiB blocks, 8 MiB at 1 KiB — and any
larger object previously failed with "alloc: no contiguous space" whatever
the image size. ext2 and ext4 were both affected.

ext4: the extent tree grows index nodes once the leaves outgrow the four
that fit in i_block, adding a level until the root fits, capped at the
kernel's depth of 5. i_blocks accounts for those nodes.

ext: a file above 4 GiB is now refused rather than silently truncated;
i_size is written as a 32-bit field and large_file is not implemented.

Validated with e2fsck plus a byte-for-byte debugfs extraction, and by
mounting under the Linux kernel: 220 MiB (inline extents), 700 MiB and a
1 KiB-block 40 MiB file (indexed trees), and an OCI-shaped 20 003-file,
732 MiB rootfs. (#14)