State of UBI

State of UBI

[Josh Boyer]

Hi all,

Where are we with UBI?  It seems Artem has been steadily committing
fixes to the ubi git tree.  There's supposedly still interest from
other projects.  Yet it hasn't been reviewed very much, for which I'm
partly to blame.  So where should we go from here?

I think a good start would be to list what's missing.  I know that it
needs a patch to allow double page writes on NAND.  There's also the
missing JFFS2 integration, or rather two competing versions of it.  Is
there anything else?  Something documented in a TODO list would be
good.

Then there's a matter of when should it be merged.  As it stands right
now, UBI is in limbo and I'd hate to see something with good potential
just sit around rotting.  Having a merge goal would perhaps provide
some motivation.  It could be a date or a kernel version, but it
should be realistic.

So lets come up with some kind of plan to get it reviewed, tested, and
merged.  My hope would be that all involved so far, or even those that
want to help out, could reply with their thoughts.  I'm afraid some
won't for various reasons.  Perhaps if some of us are going to LCA we
could get together and hash some things out more in detail, but I'd
rather not wait until then to get things moving.

josh

Re: State of UBI

[dedekind]

Hello Josh,

>Where are we with UBI?  It seems Artem has been steadily committing
>fixes to the ubi git tree. 
Yes, I'm using it in another project so I stedily add more tiny
features, changes and fixes. Also, one may notice that I maintain
UBI FAQ which has considerably grown.

>I think a good start would be to list what's missing.  I know that it
>needs a patch to allow double page writes on NAND.  There's also the
>missing JFFS2 integration, or rather two competing versions of it.  Is
>there anything else?  Something documented in a TODO list would be
>good.

Well, what you've listed is not what UBI itself needs:
1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
2. JFFS2 integration also requires zero changes in UBI (as long as it is
sane).

But, well, this is not to start a new contest :-) Let's list want to
have in UBI and around UBI.

I'd add here then:

1. True and extensive unclean reboot testing.
2. Better UBI utilities as I find the current ones not ideal.

>Then there's a matter of when should it be merged.  As it stands right
>now, UBI is in limbo and I'd hate to see something with good potential
>just sit around rotting.  Having a merge goal would perhaps provide
>some motivation.  It could be a date or a kernel version, but it
>should be realistic.

Would be nice to just add it to mtd-2.6.git, IMO. This would be a good
and simple step further.

>So lets come up with some kind of plan to get it reviewed, tested, and
>merged.  My hope would be that all involved so far, or even those that
>want to help out, could reply with their thoughts.  I'm afraid some
>won't for various reasons.  Perhaps if some of us are going to LCA we
>could get together and hash some things out more in detail, but I'd
>rather not wait until then to get things moving.

I think that we should just to merge it with mtd-2.6.git. And all the
promotion stuff may go in parallel. I'm not sure about the plan... LCA
sounds great.

I can only say that I'm going to use it extensively. And I'm already
thinking about a new - scalable UBI implementation.

Artem.

Re: State of UBI

[David Woodhouse]

On Sun, 2006-09-10 at 12:47 +0400, dedekind wrote:
> Well, what you've listed is not what UBI itself needs:
> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> 2. JFFS2 integration also requires zero changes in UBI (as long as it is
> sane).

I need to properly review UBI but I've been fairly busy on OLPC hardware
bringup so I haven't found the time yet.

Preliminary impressions are that I'm concerned by the amount of code --
it's _huge_. And I'm concerned by the fact that it doesn't just provide
MTD devices. I had envisaged that it would be fairly much akin to
another partitioning layer, perhaps requiring a few extra methods to be
added to the mtd_info. But it's a new type of device all of its own, and
requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
than I had imagined.

And should the 'static partition' stuff be a layer on _top_ of UBI
rather than an inseparable part of it?

-- 
dwmw2

Re: State of UBI

[Josh Boyer]

On 9/10/06, dedekind <dedekind@yandex.ru> wrote:
> Hello Josh,
>
> >Where are we with UBI?  It seems Artem has been steadily committing
> >fixes to the ubi git tree.
> Yes, I'm using it in another project so I stedily add more tiny
> features, changes and fixes. Also, one may notice that I maintain
> UBI FAQ which has considerably grown.

I've noticed that as well.  I think it's great and I appreciate the
effort you've put in so far.

>
> >I think a good start would be to list what's missing.  I know that it
> >needs a patch to allow double page writes on NAND.  There's also the
> >missing JFFS2 integration, or rather two competing versions of it.  Is
> >there anything else?  Something documented in a TODO list would be
> >good.
>
> Well, what you've listed is not what UBI itself needs:
> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.

I'll politely disagree here.  UBI _does_ need this on NAND to be
really usable.  Otherwise you eat 2 pages per block for UBI metadata,
and that is quite a bit of overhead for a handful of bytes in the
structures.

> 2. Better UBI utilities as I find the current ones not ideal.

What do you find lacking or not ideal?  I'm just curious.

>
> >Then there's a matter of when should it be merged.  As it stands right
> >now, UBI is in limbo and I'd hate to see something with good potential
> >just sit around rotting.  Having a merge goal would perhaps provide
> >some motivation.  It could be a date or a kernel version, but it
> >should be realistic.
>
> Would be nice to just add it to mtd-2.6.git, IMO. This would be a good
> and simple step further.

Yes, maybe.  But I don't want to put the mtd-2.6.git tree in a state
where one has to cherry pick non-UBI fixes from it to send upstream.

josh

Re: State of UBI

[Josh Boyer]

On 9/10/06, David Woodhouse <dwmw2@infradead.org> wrote:
> On Sun, 2006-09-10 at 12:47 +0400, dedekind wrote:
> > Well, what you've listed is not what UBI itself needs:
> > 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> > 2. JFFS2 integration also requires zero changes in UBI (as long as it is
> > sane).
>
> I need to properly review UBI but I've been fairly busy on OLPC hardware
> bringup so I haven't found the time yet.
>
> Preliminary impressions are that I'm concerned by the amount of code --
> it's _huge_. And I'm concerned by the fact that it doesn't just provide
> MTD devices. I had envisaged that it would be fairly much akin to
> another partitioning layer, perhaps requiring a few extra methods to be
> added to the mtd_info. But it's a new type of device all of its own, and
> requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
> than I had imagined.

Gluebi was intended to provide this translation from UBI device to MTD
device.  I don't think that is a bad approach myself.  Either way
though, JFFS2 needs to be taught not to do wear-leveling or erasing on
a UBI device.

I'll see if I can scrounge up the latest gluebi patches on Monday.  I
doubt they'll appear on this list otherwise.

josh

Re: State of UBI

[dedekind]

Hello David,

>Preliminary impressions are that I'm concerned by the amount of code --
>it's _huge_.

It's subjective. I don't know what does huge mean here. But UBI is
not larger then JFFS2 if you use the slocount program
(http://www.dwheeler.com/sloc/) you'll see it is not larger then JFFS2.

>And I'm concerned by the fact that it doesn't just provide
>MTD devices.

Just because MTD device and UBI volume are two different things. There
are similarities, but they are still different and have different
semantics.

1. UBI works on top of MTD. It's a layer above an (one) MTD device.
   MTD over MTD does not make sense.
2. Most of stuff in MTD inteface is just not needed for UBI.
3. MTD interface does not have many thins UBI needs.

>I had envisaged that it would be fairly much akin to
>another partitioning layer, perhaps requiring a few extra methods to be
>added to the mtd_info.

It'd make MTD totally confusing. Having a separate layer is less error
prone and provides better modularization.

Let me provide an example to show how clear and flexible it is.

Consider a situation when one has a NAND chip. He may want to store
kernel image at a fixed place at the beginning of the flash. And the rest
of the chip he wants to use for data storage.

So, he creates 2 MTD partitions - mtd0 and mtd1. He uses mtd0 for the
kernel image and he feeds mtd1 to UBI. So he ends up with

* mtd0 containing the kernel. He can access it via /dev/mtd0 and change it.
* mtd1 owed by UBI. But he still can access it via /dev/mtd1. E.g., this
  may be needed for debugging purposes.
* ubi0 - a UBI device which manages UBI volumes and uses mtd0 as the storage.
* ubi0_0, ubi0_1, etc - ubi volumes which may be used for JFFS2 file system.

And if the user had 2 NAND chips, he could have mtd3 which is the whole
second chip. Then he could contcatenate mtd2 and mtd3 and create one ubi0
on top of the concatenation. Or he first could apply a striping layer
(BTW, what's going on with it?) on them, and create ubi0 on top of the
striped MTD device. Or, if the chips are very different, he could create
ubi0 on top of mtd2 and ubi1 on top of mtd3 - just 2 separate and independent
UBI devices.

>But it's a new type of device all of its own, and
>requires far more to be changed in MTD users (like JFFS2, FTL, etc.)
>than I had imagined.

VS "it's a new type of device" - yes, it is new type of device by design.
And it is not an MTD device because we already have MTD devices. And it
has its own interface which is small and nice.

VS "requires far more to be changed in MTD users (like JFFS2, FTL, etc.)" -
not really. Yo may emulate an MTD device on top of an UBI device. This is
why we have (?) gluebi.

>And should the 'static partition' stuff be a layer on _top_ of UBI
>rather than an inseparable part of it?

Sorry David, I don't understand this. Refine please. What is "static
partition"? The same as "an MTD partition" - just a piece of physical
flash?

Artem.

Re: State of UBI

[dedekind]

>> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
>
>I'll politely disagree here.  UBI _does_ need this on NAND to be
>really usable.  Otherwise you eat 2 pages per block for UBI metadata,
>and that is quite a bit of overhead for a handful of bytes in the
>structures.
Josh, I politely ask you to read what I said once more, sorry :-).

I didn't say the "double page" stuff is not needed. I agree that it *is*
needed, and is very important!

What I said is that this feature requires *zero changes in UBI code*. 
It requires changes in *MTD* code. So this is why I said it
does not really relate to UBI itself, it relates to what I called
"about UBI" in the previous mail. :-) See what I mean?

>> 2. Better UBI utilities as I find the current ones not ideal.
>What do you find lacking or not ideal?  I'm just curious.

I dislike that the utilities accept UBI device number instead of UBI
character device name. And they internally form the UBI device name
using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
my UBI devices differently.

I'm partially guilty in this because I started the libubi library with
this insane feature. But I wrote it for my tests and didn't mean to
use it as a generic library. Then I created a new sane version of ubilib
but people had written most of the UBI utilities using the old insane one
by that time...

Also, the ubimkvol utility works only for ubi0 device and does not
work for ubi1 device. I did not dig why.

Artem.

Re: State of UBI

[Josh Boyer]

On 9/10/06, dedekind <dedekind@yandex.ru> wrote:
> >> 1. "double page writes on NAND" - it needs MTD changes and zero UBI changes.
> >
> >I'll politely disagree here.  UBI _does_ need this on NAND to be
> >really usable.  Otherwise you eat 2 pages per block for UBI metadata,
> >and that is quite a bit of overhead for a handful of bytes in the
> >structures.
> Josh, I politely ask you to read what I said once more, sorry :-).
>
> I didn't say the "double page" stuff is not needed. I agree that it *is*
> needed, and is very important!
>
> What I said is that this feature requires *zero changes in UBI code*.
> It requires changes in *MTD* code. So this is why I said it
> does not really relate to UBI itself, it relates to what I called
> "about UBI" in the previous mail. :-) See what I mean?

Sure, I know the changes need to be made in MTD and not UBI.  But I
think it's important enough to wait for MTD to get that fix before
merging UBI.  I didn't mean to imply that this was somehow a UBI
problem, but rather something that was hindering UBI in general.

Look at it from a user's perspective.  Someone tells you that UBI is
really cool and you should use it, but then you find out you have to
spend 4KiB per eraseblock in overhead on large page NAND devices.
It's just not that appealing.


> >> 2. Better UBI utilities as I find the current ones not ideal.
> >What do you find lacking or not ideal?  I'm just curious.
>
> I dislike that the utilities accept UBI device number instead of UBI
> character device name. And they internally form the UBI device name
> using hardcoded "/dev/ubi%d" pattern. It it insane. I may want to name
> my UBI devices differently.

Hm, ok.  I haven't looked, but that doesn't sound too hard to fix.
Perhaps the current behavior could be left as default.

> I'm partially guilty in this because I started the libubi library with
> this insane feature. But I wrote it for my tests and didn't mean to
> use it as a generic library. Then I created a new sane version of ubilib
> but people had written most of the UBI utilities using the old insane one
> by that time...

Well, nothing has been merged yet so it's easy to fix

> Also, the ubimkvol utility works only for ubi0 device and does not
> work for ubi1 device. I did not dig why.

Sounds like a bug to me.

josh

Re: State of UBI

[dedekind]

>But I think it's important enough to wait for MTD to get that fix before merging UBI.

Probably you're right, granted the waiting time is reasonable :)

Artem.

Re: State of UBI

[dedekind]

>I had envisaged that it would be fairly much akin to
>another partitioning layer, perhaps requiring a few extra methods to be
>added to the mtd_info.

To be more persuadive - I'll add to my previous mail.

It is similar to disc partitions and LVM volumes.
One can create can create several partitions. Then feed some of them to
LVM and create one or more volume groups (which is similar to UBI device(s)).
Then create logical volumes in each volume group (similar to create UBI volumes
within each UBI device).

E.g., the simplest configuration:
1. hda1 for /boot (otherwise the bootloader has to be smart and understand
   LVM tables)
2. hda2 for LVM
3. and then create as many logical volumes as you want.

And in my previous example it is similar.

1. mtd0 for the kernel (otherwise the bootloader has to be smart enough
   to understand UBI format)
2. mtd1 for UBI
3. then create as many UBI volumes as you want.

Full analogy with LVM. It'd be strange not to follow this model.

Artem.

Re: State of UBI

[David Woodhouse]

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
devices.

-- 
dwmw2

Re: State of UBI

[dedekind]

>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
>devices.

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.

Artem.

Re: State of UBI

[David Woodhouse]

On Sun, 2006-09-10 at 07:32 -0500, Josh Boyer wrote:
> I'll politely disagree here.  UBI _does_ need this on NAND to be
> really usable.  Otherwise you eat 2 pages per block for UBI metadata,
> and that is quite a bit of overhead for a handful of bytes in the
> structures.

"A handful of bytes" ought to fit into the spare area, and not take real
data pages at all.

-- 
dwmw2

Re: State of UBI

[dedekind]

>"A handful of bytes" ought to fit into the spare area, and not take real
>data pages at all.

It was actually a design decision not to use OOB area and make UBI
flash-independent. OBB area size varies, tends to be ECC-only in
new NANDs, not large enough for UBI VID header.

Artem.

Re: State of UBI

[Josh Boyer]

On 9/11/06, dedekind <dedekind@yandex.ru> wrote:
> >"A handful of bytes" ought to fit into the spare area, and not take real
> >data pages at all.
>
> It was actually a design decision not to use OOB area and make UBI
> flash-independent. OBB area size varies, tends to be ECC-only in
> new NANDs, not large enough for UBI VID header.

Yes, what Artem said.  It's more than a handful of bytes.  The EC
header and VID headers are both 64 bytes.

josh