Flash disks and FFS layout heuristics

[Matthew Dillon]

:>     64MB is tiny.  None of the problems with any of the=20
:> approachs we've discussed even exist with devices that small in an=20
:> embedded system.
:
:It is fairly clear that you're not familiar with NAND devices on
:embedded systems, as you've just said that well known problems do not
:exist.
:
:> To be clear, because I really don't understand how you=20
:> can possibly argue that the named-block storage layer is bad in a=20
:> device that small...
:
:Yes, your lack of understanding is very apparent.

    What complete bullshit.  If you want to argue technical merits, be
    my guest.  So far you haven't made one single technical point in
    any of your postings.  You've posted about your experience with NAND
    flash in embedded systems, very clearly with SMALL flash devices and
    simple filesystems, and that's fine, it's similar to my flash filesystem
    experience (which, yes, was primarily on NOR devices but, no, that
    doesn't magically make you an expert on NAND and me an idiot about it). 
    Considering I've pretty much spent my entire life working with hardware
    that is about as ridiculous an assertion as you could make, but clearly
    you believe it.

    But then you generalized to the entire market and that's not fine.

    Real filesystems are far more sophisticated then what you will ever see
    in the embedded flash product, and consequently real filesystems tend
    to broken down into more abstract terms so the higher layers can actually
    implement the filesystem functions without it taking 10 man years of
    programming.  My interest is squarely with real filesystems targetted
    to mass storage, these days.

    I didn't start out smearing people, but if you are going to start
    acting like an asshole then I have no problem ratcheting it up
    to your level.

:> It's seriously a non-issue.  You are making too many=20
:> assumptions about how named blocks would be used, particularly
:> if the filesystem is flash-aware.
:
:Now you're moving your goal posts. You came into this suggesting that
:the file system not be flash-aware. If I make the file system flash
:aware than many of the problems become managable.  That *was* my
:starting thesis, after all.

    More bullshit.  My first posting was not addressing performance issues,
    it was specifically addressing FFS and ZFS and the (bad) idea of making
    them more flash aware.  ZFS on a 2G flash device?  What the hell would
    be the point of that?  We're talking about two completely different
    things.

    It used a NOR flash translation table by way of example.  I sure as hell
    would never say that a flash-unaware filesystem would perform better
    then a flash-aware one.  Duh!

    You have seriously misread the meaning behind that posting and you
    clearly didn't read any of the other postings.  I suggest you go back
    and READ THE POSTINGS and maybe you'll start to understand the issues
    being addressed.

    Since you don't understand my position, let me lay it out for you
    in simple terms:

    * There's no point trying to adapt a flash-unaware filesystem to
      become flash-aware.  It is a complete waste of time.  You might as
      well write a new filesystem.  If you want to use a flash-unaware
      filesystem you use a translation layer, eat any performance issues,
      and be done with it.  MAYBE spend a few days optimizing the one
      or two critical paths you want to eek a little more performance out
      of.

      This has nothing to do with having to use translation tables and
      everything to do with the fact that the existance and use of those
      REQUIRED translation tables are not integrated into the flash-unaware
      filesystem, so inefficiencies are compounded rather then reduced.
      It's like jamming a square peg into a round hole.

    * Just because flash-unaware filesystems HAVE To use a translation layer
      doesn't mean that a translation layer is bad for a flash-aware
      filesystem.

    * A named-block translation layer can be an extremely valuable abstraction
      for use in filesystem designs which directly integrate its features
      (that is, the filesystem NAMES the block instead of ALLOCATES the
      block).

      There is absolutely NOTHING inherently bad about the model from a 
      performance point of view, particularly if your storage media requires
      relocation (as NAND does).  The key point is that a named-block layer
      takes over the functionality of all the indirect pointers that would
      normally have to be manipulated by higher layers in the filesystem.
      If you can integrate that into the physical storage requirements then
      you kill two birds with one stone and get major performance benefits
      from doing so.

    You are welcome to debate the points, but you'll get burned if you try
    to take some sort of moral highground stand based on a few piddly flash
    filesystems written over the course of a few years.  Coding at that
    level is fun and interesting but ultimately not very difficult.


:Feel free to implement it and see for yourself.
:
:The only point I had wished to make is that you get performance wins out
:of making the file system flash aware. Now that you've agreed to that,
:feel free to experiment with any of a number of ways of making it flash
:aware.

     Right now my work is with HAMMER.  It's fun to theorize how I could
     make HAMMER into a flash-aware filesystem but I have no intention of
     actually doing so any time soon, or ever.

     Frankly, if I wanted to write a ground-up flash filesystem I could,
     it would not be difficult... certainly not more difficult then HAMMER
     and HAMMER is probably the most sophisticated filesystem that exists
     in the open source world today.  But I have no desire to do that at
     this juncture and the lack of desire certainly does not invalidate my
     comments on the matter.

     It's kinda like saying a person has no right to comment about how to
     cut an european apples if their focus in life is cutting american ones.
     NAND is different from NOR but the differences can be explained pretty
     much in two paragraphs and most of the same concepts apply.  You can't
     byte-write, you have auxillary information, you need to add a little ECC,
     and scrub.  It isn't rocket science.

     I am a very technical person.  If you are going to argue merit, then
     you damn well better say WHY something doesn't work, in detail,
     instead of simply stating that someone random other entity couldn't
     make it work some point in the past so therefor it is bad.  If you do
     not know the WHY, precisely, then good $#%$#%$#% luck designing
     anything that's actually sophisticated.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>