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

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

Relevant Pages