In an embedded system you likely have all the code on a read-only filesystem which is the device's flash storage. You can have a separate device for writable storage (an SD card, another piece of flash, etc), or operate on a RAM disk entirely if all you need is storing runtime-only data. The latter is how OpenWRT operates, for instance.

The Linux boot image is a squashfs image loaded into memory by your boot loader (eg grub). It can still mount other filesystems for on-disk partitions (provided the relevant file system and drivers are compiled into the kernel). 50MiB is a bit on the heavy side for many embedded use cases (ie M0 devices). It’s possible M3/M4 CPUs have enough storage and RAM to support this. It’s been a while since I checked the specs for those chips.

Embedded is a broad category. Yeah, this is a bit heavyweight for Cortex-M, but so is Linux just kind of in general. This would be great for a Cortex-A class SoC.

Wondering now whether it'd be a good fit for microvms too.

Me too :-)

With a read only filesystem the value is in the simple and robust tooling for assembling the image, rather than administration of the live system.

Other embedded filesystem image generation I'm aware of (like android?) require a huge swath of software and dependencies installed, byzantine build systems, star alignment, etc. Or emulation and shell scripts with timing issues, limited failure recovery/idempotency.