Re: Reiser4 status: benchmarked vs. V3 (and ext3)

From: David Woodhouse (dwmw2_at_infradead.org)
Date: 08/14/03

  • Next message: Eli Carter: "Re: [PATCH] CodingStyle fixes for drm_agpsupport" 
    To: Yury Umanets <umka@namesys.com>
Date:	Thu, 14 Aug 2003 15:10:55 +0100

    On Thu, 2003-08-14 at 06:04, Yury Umanets wrote:
    > Yes, you are right. Device driver cannot take care about leveling.

    The hardware device driver doesn't. The 'translation layer' does, in the
    case where you are using a traditional block-based file system.

    If you consider the translation layer and the underlying raw hardware
    driver together to form the 'device driver' from the filesystem's
    perspective and in the context of the above sentence, then you're
    incorrect -- it can, and in general it _does_ take care of wear
    levelling.

    > It is able only to take care about simple caching (one erase block) in
    > order to make wear out smaller and do not read/write whole block if one
    > sector should be written.

    Whatever meaning of 'device driver' you meant to use -- no.

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

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

    > Part of a filesystem called "block allocator" should take care about
    > leveling.

    That's insufficient. In a traditional file system, blocks get
    overwritten without being freed and reallocated -- the allocator isn't
    always involved.

    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.

    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.

    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. 

    -- 
dwmw2
-
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/
  • Next message: Eli Carter: "Re: [PATCH] CodingStyle fixes for drm_agpsupport"

    Relevant Pages

    • Re: Reiser4 status: benchmarked vs. V3 (and ext3)
      ... Device driver cannot take care about leveling. ... > The hardware device driver doesn't. ... > If you consider the translation layer and the underlying raw hardware ... > The optional translation layer which simulates a block device provides ...
      (Linux-Kernel)
    • Re: Device Driver Writing To File
      ... I'm using the FC5 distro, kernel 2.6.19, and I have written a char ... device driver for a custom piece of hardware. ... is possible to open and write to a binary file on the file system from ... I'd like to monitor this hardware and log some data ...
      (alt.os.linux)
    • Device Driver Writing To File
      ... I'm using the FC5 distro, kernel 2.6.19, and I have written a char ... device driver for a custom piece of hardware. ... is possible to open and write to a binary file on the file system from ... I'd like to monitor this hardware and log some data ...
      (alt.os.linux)
    • Re: Device Driver Writing To File
      ... device driver for a custom piece of hardware. ... possible to open and write to a binary file on the file system from the ...
      (alt.os.linux)
    • Re: Stop 0A BSOD
      ... Hi Franz. ... you may have experienced some sort of a hardware failure. ... It turned out that my CPU had died, ... installing a new device driver, try uninstalling or rolling back the driver ...
      (microsoft.public.windowsxp.embedded)