lkml.org 
[lkml]   [2003]   [Aug]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Reiser4 status: benchmarked vs. V3 (and ext3)
    On Thu, 14 Aug 2003, David Woodhouse wrote:

    > The raw hardware driver provides only raw read/write/erase
    > functionality; no caching is appropriate.

    Okay, that's the model I have in mind as the driver, assuming you included
    seek in that list.
    >
    > The optional translation layer which simulates a block device provides
    > far more than simple caching -- it provides wear levelling, bad block
    > management, etc. All using a standard layout on the flash hardware for
    > portability.
    >
    > (Except in the special case of the 'mtdblock' translation layer, which
    > is not suitable for anything but read-only operation on devices without
    > any bad blocks to be worked around.)

    > If you want to teach a file system about flash and wear levelling, you
    > end up ditching the pretence that it's a block device entirely and
    > working directly with the flash hardware driver.

    I don't think that's right. A file system may very well be *optimized* for
    performance on a certain class of device, but that doesn't make it device
    dependent. For example some early SysV filesystems had the directory in
    the middle of the platters to minimize seek distance when the partition
    was only partially filled. I'd bet I could run JFFS2 on a normal drive,
    and I know I can run FAT, ext2, etc on a CF. Now if Linux only knew how to
    read SysV.4 drives I could save some critical old data from the 90's, but
    that's another issue...
    >
    > Either that or use a translation layer which does it _all_ for the file
    > system and then just use a standard file system on that simulated block
    > device.

    That sounds like a loopback mount, sort of. At least a feature which could
    be added fairly easily, like crypto mounts.
    >
    > Between those two extremes, very little actually makes sense.
    >
    > If you introduce the gratuitous extra 'block device' abstraction layer
    > which doesn't really fit the reality of flash hardware very well at all,
    > you end up wanting to violate the layering in so many ways that you
    > realise you really shouldn't have been pretending to be a block device
    > in the first place.

    Agreed, if you're going to do that type of fakery it's probably better to
    take some overhead and not give up good design in the name of performance
    for something which is usually limited by other factors like device
    performance, or seldom used. Slow and robust is easier to maintain.

    --
    bill davidsen <davidsen@tmr.com>
    CTO, TMR Associates, Inc
    Doing interesting things with little computers since 1979.

    -
    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: 2005-03-22 13:47    [W:0.020 / U:93.676 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site