标签：#yocto

Your storage hardware narrows the choice first: raw NAND requires UBIFS on UBI; ext4 and f2fs are not candidates there. On managed flash such as eMMC, our default is a read-only squashfs root plus a writable data partition, which pairs cleanly with A/B updates and integrity verification. Choose a plain ext4 root instead when your product needs a writable root and your team values familiar recovery tooling over immutability. Every embedded Linux product ships a root filesystem, and its format is often chosen by default — the vendor BSP generated ext4, so the product ships ext4. It is a real decision with long-term consequences for updates, power-cut behaviour and flash wear. This article works through the root filesystem format decision for the four realistic candidates: ext4, f2fs, squashfs with overlayfs, and UBIFS. The context The root filesystem format decision arises early, usually when the build system asks for it — Yocto through IMAGE_FSTYPES , Buildroot through its Filesystem images menu. Both can generate all four formats, so the build system does not constrain you. Five forces do. Storage technology. Raw NAND attached through the kernel's MTD layer exposes eraseblocks that wear out and can go bad; the filesystem stack must manage wear levelling and bad blocks itself. Managed flash — eMMC, SD, UFS — hides all of that behind an internal controller (an FTL) and presents an ordinary block device. Block filesystems such as ext4, f2fs and squashfs require a block device; UBIFS requires UBI on MTD. The hardware choice between raw NAND and managed flash removes half the candidates before any software argument starts. Update strategy. With image-based A/B updates — the model we recommended in Choosing an A/B Update Layout for Your Product — the root filesystem is replaced as one complete image, so a read-only format fits naturally. Package-based updates on the device require a writable root. Power-cut behaviour. Embedded devices lose power without warning. A never-w