State of UBI

dedekind dedekind at
Mon Sep 11 02:11:18 EDT 2006

>On Sun, 2006-09-10 at 21:00 +0400, dedekind wrote:
>> Full analogy with LVM. It'd be strange not to follow this model.
>Show me the changes that were made to ext3 to make it capable of
>mounting these new "LVM devices" where previously it could only do block

I love your tricky questions :-)

Ok, the analogy is indeed not full and stops here. LVM does not change
semantics - you still have block devices with 2 operation - read and write.
I noted this already.

In case of UBI we do have meny semantical changes.

* UBI volumes are bad block free even if the underlying flash may have them
  (like NAND). UBI hides this completely.
* UBI volumes wear are free, i.e., you may use the same eraseblock as much as
  you want and the wear will anyway be distributed over whole flash.
* erase is always asynchronous, i.e., you call erase and it is scheduled for
  erasure in context of the UBI background task.
* we have eraseblock type hints which are useful to let UBI know which
  eraseblock it should pick (with low erase couter, or high, or medium).
  This is not present in MTD.
* UBI maintains volume update operation. This is absent in MTD.
* UBI maintains GC hints. They are useful for a file system to to avoid
  moving eraseblock which are going to be GCed anyway. This is not present
  in MTD. And this is not implemented yet. But is planned.
* UBI maintains atomic eraseblock change operation. This means you may
  change the contents of a LEB atomically. MTD is devoid of this nice
  property which is extremely useful for FSes (e.g., you may garbage
  collect without having a spare logical eraseblock). This is not yet
  implemented but it is easy to implement and it is panned.
* UBI volumes may be dynamically created, deleted and resized. MTD
  assumes only static stuff.

I believe the list is not full. New UBI-oriented software will certainly
make use of these properties and won't work on top of MTD.

For example, JFFS3 assumes that it does not have to think about
wear-levelling. And it makes no sense to use it on top of MTD. It is
UBI-oriented. And it needs only native UBI interface.

Nevertheless, having MTD interface is not a big geal. We may make gluebi
a part of UBI. Then you'll have native interface and MTD-like interfave for
legacy software.

VS. my changes in JFFS2 which make it usable on top of UBI. As soon as we
have gluebi we can forget about it.


More information about the linux-mtd mailing list