Flash disks and FFS layout heuristics

[Martin Fouts]

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