Flash disks and FFS layout heuristics
Martin Fouts
mfouts at danger.com
Tue Apr 1 10:56:16 PDT 2008
> -----Original Message-----
> From: Matthew Dillon [mailto:dillon at apollo.backplane.com]
> Sent: Tuesday, April 01, 2008 10:33 AM
> To: Martin Fouts
> 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.
>
It has to be a data structure with certain properties, most notably
what's required to maintain consistency. It might in theory be possible
to invent such a data structure that doesn't trip over NAND performance
issues. In practice, it has not turned out to be so. I welcome your
demonstration of such a design.
> 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.
There's plenty of information on jffs2's performance problems available.
> Just saying that a blockmap or a named-block model is bad
> is wholely insufficient...
Saying that it's good, and then describing an implementation that's
known in practice to be bad is much less sufficient.
> 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.
And I've pointed out that your idea of 'large' is too large to be of
value in CE devices.
> 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.
Indeed it would be. It's good that I haven't done so.
The only times I've brought jffs2 up is when you've described approaches
that are jffs2-like, and I've pointed out that those specific approaches
have failed in jffs2.
> 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.
No, Matt, I haven't "forgotten". It's a trivial statement. At runtime
*all* topologies have in-ram and on-storage components.
> I've doing embedded work for over 20 years now,
But, by your own earlier admission, you have no experience with NAND in
such systems. It is a common mistake to extrapolate from NOR flash to
inappropriate assumptions about NAND flash.
> Large linear files are extremely well suited for
> synthetic topologies and ridiculously easy to manage the
> performance characteristics of.
"large linear files" are fairly rare on the ground in convergent
devices. What you say may well be true for a simple MP3 player, but
that's not what we're talking about here.
You've done the same thing in this email that you did in your earlier
comparison. You've found a trivial subset of the problem and then make
the generalization that solving that subset shows that the solution to
the problem is trivial.
More information about the freebsd-arch
mailing list