UBIL design doc

[Brijesh Singh]

On Mon, May 10, 2010 at 12:45 PM, Artem Bityutskiy <dedekind1 at gmail.com> wrote:
> On Sun, 2010-05-09 at 01:09 +0530, Brijesh Singh wrote:
>> Hi,
>>   I am forwarding you the design document for ubi with log. Please
>> find the ubil document at
>> http://git.infradead.org/users/brijesh/ubil_results/blob_plain/HEAD:/UBIL
>> design document.pdf
>
> Hi guys,
>
> I've read the document. Looks very promising. Here some feed-back.
>
> 1. SB PEB wear-out. What if the reaseblock lifetime is, say, 10000
> erease cycles? Won't the SB PEB wear out very quickly? Why you did not
> go for the chaining approach which I described in the old JFFS3 design
> doc?

Right.

> If we do not implement chaining, we should at least design it and make
> sure UBIL can be extended later so that SB chaining could be added.

This looks better for now. I will add it it to design.

> 2. SB PEB at the end. I think this is a very bad idea. Imagine you have
> to do UBIL images for production on the factory. With your design you
> have the following bad drawbacks:
>
>  a. NAND flash has initial bad blocks, and you do not know how many,
>     and where they sit. These may be the last 8 eraseblocks. So, when
>     you prepare an image (say, with the ubinize user-space tool), where
>     will you put the second SB PEB?
>
>  b. Currently, UBI/UBIFS images are small. E.g., if you make an
>     UBI/UBIFS image for 1GiB flash, and you have just few KiB of files,
>     your image will be few megs - it will contain the files, and all
>     the needed UBI/UBIFS meta-data.
>
>     So now what will be image size for UBIL - 1GiB, and this is bad.
>     You then will transfer 1GiB of data to the devices during flashing
>     or you will have to invent ways to work around this. Do you need
>     these complexities?
>
> I think the second SB PEB should not be at the end.
Good point. I will add it to first and second good block right now.

> 3. Backward-compatibility. In UBIL you removed EC anc VID headers in
>   PEBs. That's fine for optimization purposes. But it has draw-backs:
>
>   a. If any of the UBIL meta-data blocks like SB, CMT or log are
>      corrupted - that's it - we are screwed. You cannot anymore
>      re-consturct the data by scanning. The robustness goes down.
>
>   c. Backward compatibility - UBI will not be able to attach UBIL
>      images. This is not very nice.
>
> So, I think you should keep EC and VID headers in PEBs. And you should
> make the SB/CMT/log blocks to be a new type of UBI volume with
> UBI_COMPAT_DELETE or UBI_COMPAT_PRESERVE or UBI_COMPAT_RO type. In this
> case UBI will attach UBIL volumes just fine.
>
> Then, you can add an _option_ to have no EC/VID headers in PEBs. This
> then can be used for performance, if one wants to sacrifice robustness.
> But this should be the second step. In this case, you will just need to
> put a VID header with UBI_COMPAT_REJECT flag to the first PEB.
>
> I have some more notes, but these 3 are enough for now.
>
> What do you think?
This is nice. But I need to think a bit. I will get back on this.