Grow UBI device?

[Richard Weinberger]

On Wed, Oct 9, 2013 at 5:45 PM, Ricard Wanderlof
<ricard.wanderlof at axis.com> wrote:
>
> On Wed, 9 Oct 2013, Wolfgang Denk wrote:
>
>>>> 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.
>>
>>
>> Mounting UBIFS volumes should not be a problem - the existing ones are
>> not located in the newly added area of the NAND.  The question however
>> is what the UBI layer itself does, if I for example try to create a
>> new volume which then would allocate blocks from the newly added
>> space.
>
>
> UBI scans the whole partition when the attachement is made to the mtd
> partition. So if you'd get any error message regarding blocks that lack UBI
> headers it would be then, not when you subsequently try to create a volume
> in the partition. By that time the volume should be "formatted" with valid
> UBI headers.
>
>
>>> 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).
>>
>>
>> Are you sure about that?
>>
>> Well, I guess I'll have to try it out in the end...
>
>
> I just tested it since I have a UBI system just beside me, by erasing and
> then writing zeros to a block (just to put non-UBI data in it) and
> restarting the system (the partition in question contains the volume with
> the root file system in it, so it is attached by the kernel during its
> boot). The result was that UBI didn't give any error or warning messages
> during boot, but a subsequent nanddump after boot revealed that the zeroed
> blocks now contained valid UBI headers, so, without looking at the source,
> it seems that UBI really does manage this fairly silently.

I've never tested this. But from my understanding of the UBI source
this behavior is
correct and intended. (Of course only in the non-fastmap case).

-- 
Thanks,
//richard