UBIFS Question

[Laurent .]

Hi Artem,

> OK. BTW, I've written a small article which should help people
> understand how UBI flashers should work, roughly:
> http://www.linux-mtd.infradead.org/doc/ubi.html#L_format

Thanks.

For now, I am only going to use my flasher in factory, when the flash is blank,
so I don't have to deal with erase counters.
However, your article will be useful when I will have to code
a firmware upgrader :-)

Related to the BBT and MTD in general, do I have to reserve a few blocks
outside the partitions, in case of one of the mirrored bbt goes bad ?
What does MTD do if it sees it could not update one of the two blocks ?
Does it grab a fresh block outside the partitions ? or can it pick a
block from anywhere (since that block won't be mark as 'good' anymore
anyways, it should not mess up with the partition) ?

>
> Take into account that if you have a power cut, then next mount will be
> slower than normal, because UBIFS will have to replay the journal and
> do recovery. So if mount time is critical, you may want to test it in
> power-cut conditions.
>

That's an important point for my application, I need fast mount time
( who does not anyways ? ;-) )

However, I can assume that when the file system is going to be written to,
it is very unlikely that the user will power off the unit right away.
Then, I presume that I should be fine since I am going to use a
rather short (5 sec) dirty timeout ?

 From what you wrote about the sync, I should be able to write my code so
that I will greatly minimize the risk of power-off while the file system 
s still "dirty" and there are still stuff to commit.
So, just to be sure, if the file system is dirty, and the time out occur and
all data are commited, it is safe to power off the unit and
next mount will be fast, correct ?

> Hmm, which version of mkfs.ubifs you use? I though the latest version
> would create an image with a reserve for the root. Try
> "mkfs.ubifs --version" please.

Version 1.3

> Depends of the system. I'd recommend something like 5 seconds
> for embedded systems.

OK. I presume that if there is nothing new "to commit",
there is only very small overhead introduced every 5 seconds, correct ?

Well, thanks a lot for your detailed answered about that "ghost" file phenomenon.
It all makes sense to me.

Regards,
Laurent

_________________________________________________________________
Hotmail® has ever-growing storage! Don’t worry about storage limits. 
http://windowslive.com/Tutorial/Hotmail/Storage?ocid=TXT_TAGLM_WL_HM_Tutorial_Storage_062009