Re: [PATCH 00/22 take 3] UBI: Unsorted Block Images

[Theodore Tso]

On Tue, Mar 20, 2007 at 10:59:55AM -0500, Josh Boyer wrote:
> Sure.  But the larger question is *should* it be extended to do so.

Absolutely, and so let's focus on that.

> Except that flash filesystems don't use block devices at all.  They use
> MTD interfaces.

Yes, so that would be first issue.  We would need to change the flash
filesystems to the block interface issue, and expand the block device
to use MTD.  Now, maybe Matt is conversant about what would be
involved to do this, but I will admit to being MTD ignorant.  But if
that's there is a huge impendance mismatch right there, that that
might be enough to kill it right there.

> > high-level architecture of what UBI is trying to achieve.  What are
> > the interfaces at the top and the bottom of the stack?  For example,
> > the fact that UBI exports Logical Erase blocks that are not a
> > power-of-two (possibly 128k minus 128 bytes) means that it certainly
> > might not be a good match for the dm stack.  But why is that the case?
> > I can imagine good reasons for it, but a high-level description of the
> > design decisions would be very useful.
> 
> Basically because you need to store metadata in each eraseblock (and not
> in OOB).  That metadata consumes space reducing the usable storage in
> each eraseblock by an amount and making it no longer a power-of-two.

So this is probably a stupid question, but what drives the design
decision to store the metadata in-band instead of out-of-band (and you
don't have to answer me here; putting it in the overall system
architecture document is just as good, and probably better.  :-)

> > It would also help people understand why there are so many "units" in
> > UBI, since hopefully the high-level documentation would explain why
> > they fit together, and perhaps why some of the units weren't folded
> > together.  What value do they add as separate components?
> 
> Artem is reworking the units per your (and other's) suggestions.  The
> debugging code is also being worked on.

As I mentioned to you in IRC, in the future if there is pending
changes in response to reviewer comments, it might be a good idea to
mention that, so that reviewers know not make those comments again, or
worry that the comments had been ignored.

> > There are hints of the overall system architecture in some of the
> > indivdual comments for data structures, but even reading all of those,
> > there isn't quite enough for people to figure out what it is; and that
> > may be causing some of these comments of people saying there's too
> > much code to evaluate, or why didn't you do it *this* way?   
> 
> Some of that can probably be added, sure.  Though to be fair, it'll add
> even more lines to the patch and those links have been posted 4 times
> already.  They're even posted at the start of _this_ thread.  Having it
> in the patch under Documentation/ is a good idea, but you can't force
> people to read that before they comment on things.

Well, having spent some time looking at the FAQ's and all of the
comments kernel docs embedded in the header files and source files,
there are sections that I would move to an overall system architecture
documentation, but there is still a lot that was missing that makes it
hard to review the patches.  I'm sure a lot of it is my own ignorance,
but that's probably one of the challenges with the UBI layer; not as
more people have a basic background in say say scheduling or VM or
filesystem than there are people who have a basic background in flash
devices.

Regards,

						- Ted

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/