Migrating to UBI Volumes, keeping some data

Migrating to UBI Volumes, keeping some data

[Sven Eisenberg]

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.

The kernel level is ~3.10.y.

Thanks and regards,
Sven Eisenberg

-- 
Sven Eisenberg

Novero gmbh | Meesmannstr. 103 | 44807 Bochum  | Germany

Novero GmbH | Parsevalstr. 7a | 40468 Düsseldorf | Germany | Amtsgericht Düsseldorf | HRB 58283 | Umsatzsteueridentifikationsnummer: DE 814973142 | Geschäftsführer: Freddie Geier

Re: Migrating to UBI Volumes, keeping some data

[Richard Weinberger]

On Mon, Jan 25, 2016 at 5:21 PM, Sven Eisenberg
<sven.eisenberg@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