While I think it is a good practice to use separate file system for data/configuration and the rootfs, I don’t think it is solving your data integrity issue… Just creating a second file system instance won’t change the behavior of the file system… This answer consists of two parts:
Ensure data integrity
Ensuring data integrity is not as easy as it seems. Especially nowadays file system optimize a lot and try to delay writes as much as possible. Using fsync() after writing data to the file should make sure data hit the NAND flash, but there is still a window in which the file could end up being empty (what happens if power gets lost during fsync?). Especially, it does not guarantee that the old data are still there. The common approach is to create a new, temporary file, write data, fsync() that file, and then do the renaming and a final fsync on the directory. Refer also to this LWN article for more info.
Creating independent UBIFS instances
You can partition the NAND flash on different levels:
- Create separate MTD partitions
- Create separate UBI volumes
Creating separate MTD partitions splits up the NAND flash in physical separated areas. Our BSP by default uses separate areas for the boot block and boot loader only, all the rest is in a single MTD partition (called ubi, see also the output of the mtdparts command in U-Boot). Having only one big partition allows to reserve blocks for bad block management only once. A NAND device makes guarantees that not more than a certain amount of blocks will turn bad within the guaranteed life cycle (e.g. ~5% or 20 blocks in the VF50 case). However, this could be clustered, so if you partition the device on a physical level, you will have to reserve 20 blocks for each partition…
Create separate UBI volumes does not have that draw back: UBI reserves blocks for bad block management for the whole device, and can remap them dynamically between UBI volumes. However, in case there is a bug in the UBI layer, it could be that one file system corrupts the other instance… I would not assume that since UBI has been tested quite extensively.
Creating a UBI volume can be done in Linux or U-Boot. Our update/write scripts use the U-Boot ubi create command (see flash_blk.scr). You can alter those scripts, or create the partitions manually. However, to change volume layout, you first need to delete the existing volumes using ubi remove. E.g. this create a data partition of 32MiB and allocates the rest to a root partition and write the root file system to it:
run setupdate
run prepare_ubi
ubi remove rootfs
ubi create data 0x2000000
ubi create rootfs 0 dynamic
run update_rootfs
To make sure the volume gets mounted on every boot, extend /etc/fstab a line like this:
ubi0:data /mnt ubifs defaults