lkml.org 
[lkml]   [2007]   [Mar]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH 00/22 take 3] UBI: Unsorted Block Images
    From
    Date
    On Wed, 2007-03-21 at 12:05 +0100, Jörn Engel wrote:
    > On Tue, 20 March 2007 01:42:46 +0100, Thomas Gleixner wrote:
    > > On Mon, 2007-03-19 at 17:32 -0500, Matt Mackall wrote:
    > >
    > > > > > 4. JFFS2 has its own wear-leving scheme, as do several other
    > > > > > filesystems, so they probably want to bypass this piece of the stack.
    > > > >
    > > > > JFFS2 on top of UBI delegates the wear levelling to UBI, as JFFS2s own
    > > > > wear levelling sucks.
    > > >
    > > > Ok, fine. How about LogFS, then?
    > >
    > > LogFS can easily leverage UBI's wear algorithm.
    >
    > Ok, now we have reached the absurd. UBI quite fundamentally cannot do
    > wear leveling as good as LogFS can. Simply because UBI has zero
    > knowledge of the _contents_ of its blocks. Knowing whether a block is
    > 90% garbage or not makes a great difference.
    >
    > Also LogFS currently requires erasesizes of 2^n.

    Last time I talked to you about that, you said it would be possible and
    fixable. We talked about several mechanisms, which would allow a
    filesystem or other users to hint such things to UBI.

    Even if the LogFS wear levelling is so superior, it CAN'T do across
    device wear levelling.

    tglx


    -
    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-21 12:21    [W:4.282 / U:0.096 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site