lkml.org 
[lkml]   [2007]   [Mar]   [20]   [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 Tue, 20 Mar 2007, Josh Boyer wrote:

    > On Tue, 2007-03-20 at 09:52 -0400, Theodore Tso wrote:
    >> As a suggestion, let's stop right here and see if we can get both
    >> sides talking in a more constructive fashion. Maybe it's just me, but
    >> I see both sides talking past each other in a rather dramatic fashion.
    >
    > Perhaps, yes. Though I've been trying to be open to Matt's suggestions.
    > Please don't mistake confusion for hostility.
    >
    >> There a number of red herrings that have been introduced in this
    >> discussion; of *course* the existing block device layer can handle
    >> FLASH devices; Matt is proposing that they be extended. And of
    >
    > Sure. But the larger question is *should* it be extended to do so.
    >
    >> *course* you woulnd't propose to use ext2 on top of an 128k blocksize,
    >> anymore than you would force a flash filesystem to use a 4k or 512
    >> byte blocksize; there are plenty of configurations that won't make
    >
    > Except that flash filesystems don't use block devices at all. They use
    > MTD interfaces.
    >
    >> sense, and by itself this isn't an indictment of the core idea that
    >> the block device layer and dm should be augmented to encompass flash
    >> functionality.
    >
    > This is where the concept starts to lose me. Augmented how? To not use
    > MTD at all (obviously with the exception of the low-level flash
    > drivers)? How is that not going to duplicate MTD? Etc, etc.

    What Matt and Ted are looking at is the question 'are flash devices close enough
    to other block devices that it would make sense to change the existing linux
    definition of a block device to handle the special requirements of flash'

    if the block device layer can be reasonably modified to accomodate flash, then
    doing so greatly improves flexibility and maintainability. It would also reduce
    the overall code size since existing features of the block layer (for example
    snapshots) would not need to be duplicated or re-written for the flash block
    layer.

    if not then so be it.

    everyone understands that flash has different requirement from a hard drive as a
    block device, what isn't clear to the people reading this thread (and reviewing
    the code) is why you believe that it is _so_ different that it's impossible to
    consider extending the linux definition of a block device.

    the fact that the native eraseblock size is significantly larger isn't a factor.

    the fact that you erase in large blocks and then write in smaller blocks is a
    difference, and one that the current block layer doesn't understand. but this is
    a difference that the current block layer could be changed to understand. it's
    not something that would justify a seperate-but-equal block layer for flash
    devices.

    as Ted notes, the idea that block sizes may not be powers of 2 (128k-128b from
    his e-mail) _may_ end up being a big enough difference that it's not worth
    teaching the exising block layer how to deal with, but it's not clear why you
    are useing this odd size.

    this is why you are being asked for further explinations.

    David Lang
    -
    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-20 20:27    [W:4.338 / U:0.008 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site