[lkml]   [2007]   [Mar]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 00/22 take 3] UBI: Unsorted Block Images
    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.

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

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

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

    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
    More majordomo info at
    Please read the FAQ at

     \ /
      Last update: 2007-03-19 18:25    [W:0.023 / U:1.700 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site