Migrating to UBI Volumes, keeping some data

[Richard Weinberger]

On Mon, Jan 25, 2016 at 5:21 PM, Sven Eisenberg
<sven.eisenberg at novero.com> wrote:
> Hello all
>
> I'm facing a common mistake with UBI, we have a system that has nand
> partitioning on the MTD layer.
>
> Partitions:
> mtd1: root
> mtd2: dynamic_data
> mtd3: other_data
> mtd4: static_data
>
> We have learned the lesson with reduced wear leveling and degraded bad
> block pools. Now i plan to migrate also systems in the field to a UBI
> volume partitioning concept.
>
> The challenge for me is the data migration of the "static_data"
> partition, it is quite big and re-writing the data in the field is not
> an option.
> Erasing and re-writing the other partitions is not a problem in my
> situation. We run the kernel from NOR and have initial data to start from.
>
> After thinking about it i have the following theory of how a migration
> could work and I'd like to ask if you also think this is a possible way
> or if it is a stupid idea maybe:
>
> Target: migrate, but keep the volume in mtd4.
> The system is launched with the old mtd partitioning scheme, and does a
> flash_eraseall on mtd1, mtd2, mtd3 but not on mtd4.
> Then we reboot with only a single full size MTD configured in the kernel.
> Will the kernel UBI scan code be able to merge the erased blocks and the
> existing blocks from mtd4 into a consistent UBI device?
> The erased blocks should be initialized with the UBI headers, so we can
> define the remaining UBI volumes in the next step and initialize the
> system with data.
>
> I'm aware that by flash_eraseall the erase counters will be lost in mtd1-3.

Yes, that approach should work.
But I'd test it first. ;-)
Also think of power cuts...

Maybe it would make sense to add interface to UBI such that userspace
can set the erase counter
of PEBs. This would allow us to build a nice UBI migration framework.
*pushes to never ending TODO list*

-- 
Thanks,
//richard