Date: Tue, 1 Apr 2008 15:26:04 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Martin Fouts" <mfouts@danger.com> Cc: freebsd-arch@freebsd.org Subject: RE: Flash disks and FFS layout heuristics Message-ID: <200804012226.m31MQ42O042173@apollo.backplane.com> References: <20080330231544.A96475@localhost> <200803310135.m2V1ZpiN018354@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D03@EXCHANGE.danger.com> <200803312125.29325.qpadla@gmail.com> <200803311915.m2VJFSoR027593@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D09@EXCHANGE.danger.com> <200803312219.m2VMJlkT029240@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D0F@EXCHANGE.danger.com> <200804011748.m31HmE1h039800@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D19@EXCHANGE.danger.com> <200804012010.m31KAMpu041011@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D1D@EXCHANGE.danger.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> 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@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804012226.m31MQ42O042173>