Grow UBI device?

[Gupta, Pekon]

> From: Ricard Wanderlof
> > On Tue, 8 Oct 2013, Wolfgang Denk wrote:
> > I'm looking for a clever way to migrate devices (in the field) from
> > JFFS2 to UBI/UBIFS.  In the end result, I want to have single UBI
> > device (which covers the whole NAND chip) with several volumes used
> > with UBIFS.  Unfortunately I must keep some of the existing data.
> >
> > It would be nice if I could start with a UBI device that is smaller
> > than the NAND, so I can keep an existing MTD partition with a JFFS2
> > file system. After copying the data from JFFS2 to a UBIFS volume, I
> > would like to free and reuse the space of this JFFS2 partition.
> >
That seems to be a nice move, but where would you copy the existing
JFFS2 data ?
(a) In memory, then there is threat of losing the data due to
  power-failure, and you should have enough RAM.
(b) copy to target UBIFS volume/partition. So assumption is that target
  UBI volume has enough space and is writable.
I'm assuming (b) is more workable .. 


> > Is there a way to "grow" the existing UBI device so that it now also
> > covers the rest of the NAND chip?  Or is my only option to create a
> > second UBI device?
> 
> UBI devices are 'attached' to existing mtd partitions. So to grow a UBI
> device, you need to detach it from the partition, re-partition the flash
> (and I'm not sure if this step is even possible as it involves
> unregistering existing mtd partitions), then attach a UBI device to the a
> new partition.
> 
Yes, currently registering and de-registering of MTD partitions are
done as part of nand_probe() and nand_remove().
If we do on-the-fly registering / de-registering of MTD device, then we
also need to tweak the mtd partition information, which will change
- partition base offset and 
- shift masks (to calculate offset within the partition)
which is ok, because they are not used by controller drivers directly.


> Come to think of it, I'm not sure that would work anyway, as the
> resulting, new, enlarged partition would partly contain UBI data and
> partly old jffs2 data. I'm not sure what UBI does when it encounters
> incorrect data, if it just erases the relevant blocks and formats them for
> its own use, or if it barfs completely and just bails out complaining that
> the partition does not contain UBI data. If the relevant blocks were
> erased, then I think UBI would simply concede that the a previous erase
> attempt had been prematurely aborted, and re-erase the blocks and write
> its headers, so perhaps that is something to try. At any rate it involves
> at least some mild trickery (erase the blocks that previously contained
> jffs2 data).
> 
Yes, during mounting of UBIFS volumes, UBI checks for erase-header
on first-page of every block. 
- If it's able to find a valid erase-header, with correct image_seq field,
then it attaches it to its pool.
- Otherwise, if the valid erase-header was not found, then it assumes
 then it ubi will try re-erasing it. And add it to its pool of free-blocks.

So, effectively you don't even need to erase the partition to convert
it into UBI volume, you just try attaching it as UBI volume and UBI
should erase it for you. (though flagging some warnings on the way).


> It's probably easier to create a new UBI device by attaching it to the
> partition previously used by jffs2, after erasing it, but multiple UBI
> devices across a flash partly defeats the purpose of wear-leveling which
> UBI provides.
>
True but this is good for on-field devices which are still on JFFS2 and
want to migrate to UBIFS for same reasons. Also, this would help in
other areas like recovery from power-failures.
 

with regards, pekon