UBIL design doc
brijesh.s.singh at gmail.com
Mon May 10 06:31:31 EDT 2010
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:
>> I am forwarding you the design document for ubi with log. Please
>> find the ubil document at
>> 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
> 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.
More information about the linux-mtd