lkml.org 
[lkml]   [2007]   [Mar]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH 00/22 take 3] UBI: Unsorted Block Images
    On Sun, Mar 18, 2007 at 06:49:39PM +0200, Artem Bityutskiy wrote:
    > On Sun, 2007-03-18 at 11:27 -0500, Matt Mackall wrote:
    > > Forgive my ignorance, but why did you not implement the two features
    > > above as device mapper layers instead? A device mapper can arbitrarily
    > > transform I/O addresses and contents and has direct access to the
    > > mapped device's ioctl interfaces, etc.
    >
    > Just because UBI is designed for flash devices, not block devices. Note,
    > UBI is not for MMC/USB stick/SC/etc flashes, which are used as block
    > devices, but for _bare_ flashes.
    >
    > Please, glance here to find more information about the different between
    > flashes and block devices:
    >
    > http://www.linux-mtd.infradead.org/faq/general.html#L_mtd_vs_hdd

    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

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

    --
    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@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-03-18 20:33    [W:4.514 / U:0.476 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site