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 > > 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. > 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. > a level. As I've pointed out already, you can already easily address > issues two, four, and five with device mapper layers. > > If instead you still want the "NAND-ness" of the device exposed at the > top level so things can do raw eraseblock I/O more efficiently, then I > think instead of duplicating the device mapper framer, we should > instead think about how to integrate NAND devices more closely with > the block layer. > > 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. UBI is about maximizing the number of available eraseblocks to efficiently wear-level across the largest possible area on a flash chip. MTD itself contains no higher-level capabilities to deal with this, and UBI uses the underlying MTD device directly, not through ioctls. This allows existing flash specific users (e.g. JFFS2) to run on top of UBI with minimal changes. Your idea does have some merit, however I believe your focus is misplaced. Rather than convert UBI to device mapper and somehow try to make it work through mtdblock (sic), perhaps what should be done is come up with a better interface for MTD to present itself as a block device. I would still find that troubling though. josh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
