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

From: Josh Boyer
Date: Mon Mar 19 2007 - 14:17:00 EST


On Mon, 2007-03-19 at 12:08 -0500, Matt Mackall wrote:
>
> > > If the end goal is to end up with something that looks like a block
> > > device (which seems to be implied by adding transparent wear leveling
> >
> > Nope, not the end goal. It's more about wear-leveling across the entire
> > flash chip than it is presenting a "block like" device.
>
> It seems to be about spanning devices and repartitioning as well.
> Hence the analogy with LVM.

Yes, it can span multiple MTDs which spreads the wear-leveling even
more. Yes, it can create/resize/remove volumes. It does that
differently than LVM, but the ideas are related. I don't see the issue
here I guess.

(UBI also has static volumes which LVM doesn't but that is an aside.)

> > > and bad block remapping), then I don't see any reason it can't be done
> > > in device mapper. The 'smarts' of mtdblock could in fact be pulled up
> >
> > There is nothing smart about mtdblock. And mtdblock has nothing to do
> > with UBI.
>
> Note the scare quotes. Device mapper runs on top of a block device.
> And mtdblock is currently the block interface that MTD exports. And it
> has 'smarts' that hide handling of sub-eraseblock I/O. I'm clearly
> talking about an approach that doesn't involve UBI at all.

Ok, but what I'm saying is that using device mapper on top of mtdblock
is not a good solution. mtdblock caches writes within an eraseblock to
a DRAM buffer of eraseblock size. If you get a power failure before
that is flushed out, you lose an entire eraseblock's worth of data.
Oops. And if you constantly flush the buffer, there's no point in
having it in the first place because it doesn't help or hide anything
then. UBI doesn't have this problem.

That's why I suggested fixing the MTD layers that present block devices
first in the part of my reply that you cut off. It seems to me that
you're really after getting flash to look like a block device, which
would enable device mapper to be used for something similar to UBI.
That's fine, but until someone does that work UBI fills a need, has
users, and has an existing implementation.

josh

-
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/