lkml.org 
[lkml]   [2007]   [May]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [PATCH] LogFS take three
    FromDavid Woodhouse <>
    DateThu, 17 May 2007 14:25:17 +0800
    On Thu, 2007-05-17 at 15:12 +0900, Dongjun Shin wrote:
    > The current trend of flash-based device is to hide the flash-specific details
    > from the host OS. The flash memory is encapsulated in a package
    > which contains a dedicated controller where a small piece of software (F/W or FTL)
    > runs and makes the storage shown as a block device to the host.

    Yes. These things are almost always implemented _very_ badly by the same
    kind of crack-smoking hobo they drag in off the streets to write BIOSen.

    It's bog-roll technology; if you fancy a laugh try doing some real
    reliability tests on them time some. Powerfail testing is a good one.

    This kind of thing is OK for disposable storage such as in digital
    cameras, where it doesn't matter that it's no more reliable than a
    floppy disc, but for real long-term storage it's really a bad idea.

    > IMHO, for a flash-optimized filesystem to be useful and widely-used, it would be better
    > to run on a block device and to be designed to run efficiently on top of the FTL.
    > (ex. log-structured filesystem on general block device)

    There's little point in optimising a file system _specifically_ for
    devices which in often aren't reliable enough to keep your data anyway.
    You might as well use ramfs.

    It's unfortunate really -- there's no _fundamental_ reason why FTL has
    to be done so badly; it's just that it almost always is. Direct access
    to the flash from Linux is _always_ going to be better in practice --
    and that way you avoid the problems with dual journalling, along with
    the problems with the underlying FTL continuing to keep (and copy around
    during GC) sectors which the top-level filesystem has actually
    deallocated, etc.

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

    \
     
     \ /
      Last update: 2007-05-17 08:29    [from the cache]
    ©2003-2010