Re: mkfs.erofs: --incremental=data segfaults when appending without -z to compressed image

[Gao Xiang <xiang@kernel.org>]

Hi Matthew,

On Wed, Oct 21, 2026 at 07:13:18AM -0400, Matthew Lear wrote:
> Hi,
> I've been experimenting with appending to a base erofs image to try and
> optimise for in-place updates. By appending 'volatile' paths (which are
> anticipated to change more frequently between updates) at the end of
> the image, the amount of write IO the device will sustain when applying
> the update is reduced. I've noticed that if appending an erofs image
> created without -z to a base that was created with -z, mkfs.erofs
> segfaults. The compression scheme does not matter (I tested zstd, lzma
> and deflate).
> 
> The reverse is not true - an uncompressed base with a -z append is successful.
> In that case, fsck passes, contents seem intact, the superblock gains
> the compression feature and the appended files appear to be stored
> compressed. The failure only happens one-way.
> 
> I've seen this on an arm64 box (Raspberry Pi 5) but it also happens on
> my x86 box, too:
> 
> Versions
> - erofs-utils 1.9.4
> - dev at 27a171f (1.9.4-g27a171f5)
> 
> Environment: x86_64, Ubuntu 24.04, gcc 13.3.0, libzstd 1.5.5, liblzma
> 5.4.5
> 
> Configured with:
> --with-libzstd --without-selinux --enable-multithreading
> --disable-static --disable-fuse MAX_BLOCK_SIZE=16384
> 
> plus --disable-lzma for the zstd and deflate runs (LZMA enabled for the
> lzma runs).
> 
> Reproduce with:
> 
> mkdir -p b a
> echo base > b/f
> head -c 4097 /dev/zero > a/g
> 
> mkfs.erofs -zzstd i.erofs b
> mkfs.erofs --incremental=data i.erofs a
> 

Sorry I'm very busy these days.

Yes, currently for incremental builds, you need to explicitly pass the
same compression set as the base images.

> Backtrace below:
> 
> Thread 2 "mkfs.erofs" received signal SIGSEGV, Segmentation fault.
> #0  erofs_compress_destsize (c=0x555556177390, src=..., srcsize=...,
> dst=<g_dstbuf+4096>, dstsize=4096) at compressor.c:82
> #1  __z_erofs_compress_one (e=<optimised out>, ctx=<sctx>) at compress.c:634
> #2  z_erofs_compress_one (ctx=<sctx>) at compress.c:796
> #3  z_erofs_compress_segment (ctx=<sctx>, offset=18446744073709551615,
> pstart=4096) at compress.c:1379
> #4  erofs_write_compressed_file (ictx=<optimised out>) at compress.c:2172
> #5  erofs_mkfs_job_write_file (...) at inode.c:1534
> #6  erofs_mkfs_handle_nondirectory (...) at inode.c:1594
> #7  erofs_mkfs_jobfn (...) at inode.c:1666
> #8  z_erofs_mt_dfops_worker (...) at inode.c:1741

It's an explicit ask for now, so that firstly we need to avoid
the segfault and bail out gracefully if the compression set isn't
pass in.

But I agree that we need to read the compression set (by reading
on-disk compression configuration) instead of relying on user
inputs as a future enhancement.

Thanks,
Gao Xiang

> 
> It occurs with zstd, lzma and deflate bases, and with both -b 4096 and
> -b 16384.
> Appending with a different compression algo fails cleanly, eg:
> 
> zstd base + -zlzma append:  <E> erofs: unavailable algorithms 0x2 on
> incremental builds
> lzma base + -zzstd append:  <E> erofs: unavailable algorithms 0x8 on
> incremental builds
> 
> Regards,
> --  Matt
>