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

[Matt Mackall <mpm@selenic.com>]

On Mon, Mar 19, 2007 at 08:03:30PM +0100, Thomas Gleixner wrote:
> Matt,
> 
> On Mon, 2007-03-19 at 12:08 -0500, Matt Mackall wrote:
> > On Sun, Mar 18, 2007 at 03:31:50PM -0500, Josh Boyer wrote:
> > > On Sun, Mar 18, 2007 at 02:18:12PM -0500, Matt Mackall wrote:
> > > > 
> > > > I'm well aware of all that. I wrote a NAND driver just last month.
> > > > Let's consider this table:
> > > > 
> > > > HARD drives                          MTD device
> > > > Consists of sectors                  Consists of eraseblocks
> > > > Sectors are small (512, 1024 bytes)  Eraseblocks are larger (32KiB, 128KiB)
> > > > read sector and write sector         read, write, and erase block
> > > > Bad sectors are re-mapped            Bad eraseblocks are not hidden
> > > > HDD sectors don't wear out	     Eraseblocks get worn-out
> > >  N/A                                   NAND flash addressed in pages
> > >  N/A                                   NAND flash has OOB areas
> > >  N/A (?)                               NAND flash requires ECC
> > 
> > Disks have OOB areas with ECC, it's just nicely hidden inside the
> > drive. They also typically have physical sectors bigger than 512
> > bytes, again hidden.
> 
> The difference is that the harddrive has an intellegent controller,
> which hides all this away. NAND FLASH has not and we have to do it in
> software.
> 
> > > > 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, UBI is a kind of LVM for FLASH and we did think quite a time about
> reusing LVM before we went the UBI way.
> 
> > > > 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.
> 
> MTD block has no 'smarts' at all. It is a stupid and broken hack, which
> you can utilize to lose data and wear your FLASH out. 

I explained precisely what I meant by 'smarts' and why I put it in
'smarts' in quotes. And here you are repeat that same exact damn thing
I responded to five lines up.

> > > > In the end, a block device is something which does random access
> > > > block-oriented I/O. Disk and NAND both fit that description.
> > > 
> > > NAND very much doesn't fit the "random access" part of that.  For writes
> > > you have to write in incrementing pages within eraseblocks.
> > 
> > And? You can't do I/O smaller than a sector on a disk.
> 
> Should we export block devices with 16/32/64/128 KiB size ?

Sure, why not?

> A disk _IS_ fundamentally different to FLASH and all the magic which is
> done inside of CF-Cards and USB-Sticks is just hiding this away.

And yet they're still both block devices. That our current block layer
doesn't handle one as well as the other is something we should fix
instead of inventing a whole new full-feature but incompatible block
layer on the side.

-- 
Mathematics is the supreme nostalgia of our time.