Date: Tue, 1 Apr 2008 10:33:15 -0700 (PDT) From: Matthew Dillon <dillon@apollo.backplane.com> To: "Martin Fouts" <mfouts@danger.com> Cc: Christopher Arnold <chris@arnold.se>, arch@freebsd.org, qpadla@gmail.com, freebsd-arch@freebsd.org Subject: RE: Flash disks and FFS layout heuristics Message-ID: <200804011733.m31HXF6e039649@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> <200803312006.m2VK6Aom028133@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D0A@EXCHANGE.danger.com> <200803312254.m2VMsPqZ029549@apollo.backplane.com> <B95CEC1093787C4DB3655EF330984818051D0D@EXCHANGE.danger.com>
next in thread | previous in thread | raw e-mail | index | archive | help
:> with the blockmap layer entirely since seek locality of=20
:> reference is not needed for a flash filesystem, and the global
:> B-Tree would serve directly as the named-block topology.
:
:Which would lead you almost directly to the sort of performance problems
:that jffs2 has.
:
:Until you've done it, you'll be surprised at the cost of maintaining
:b-trees in NAND.
Well, I'm not advocating a B-Tree storage model for indexing in NAND.
That would be kinda nasty. What I've done is simply describe a mechanism
whereby a filesystem topology is able to make use of an abstraction to
the point of being able to do away with what would normally have to be
implemented by the filesystem itself. It doesn't have to be a B-Tree.
You keep mentioning jffs2 and you keep mentioning 'the sort of
performance problems that jffs2 has'... ok, but you aren't actually
saying what they are with any specificity. Just saying that a blockmap
or a named-block model is bad is wholely insufficient... it's way too
broad a brush that ignores the literally thousands of ways such
entities can be implemented. I've described numerous ways such entities
can work, particularly if one is manipulating large blocks. If you
want to address those please feel free but holding up jffs2 as a poster
child of fail for an entire class of storage modeling is stupid.
Please also remember, since you've appeared to have forgotten, that
topologies can be implemented in both ram and storage together and
are NOT necessarily ram intensive. This is going to be particularly
true for any application reading or writing large files, such as an
audio application, and is even more particularly true when dealing
with fairly large files in fairly small amounts of storage. Synthesis
is a major design component for small scale filesystems.
I can't comment on your filesystem specifically, but you are welcome
to describe it in more detail.
I've doing embedded work for over 20 years now, everything from single
chip microcomputers with 256 bytes of ram to little ARM chipsets running
linux. I still have all that goddamn machine code burned into my brain,
in fact, like a lost cousin. Please do not make the inference that I
somehow do not understand the issues involved. I know precisely what
the issues are and I will only repeat that for small scale devices,
particularly recording and playback devices, the filesystem design
devolves into trivialities that are easily cached, even if you don't
have a lot of ram. Large linear files are extremely well suited for
synthetic topologies and ridiculously easy to manage the performance
characteristics of.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200804011733.m31HXF6e039649>