Date: Tue, 1 Apr 2008 10:56:14 -0700 From: "Martin Fouts" <mfouts@danger.com> To: "Matthew Dillon" <dillon@apollo.backplane.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: <B95CEC1093787C4DB3655EF330984818051D17@EXCHANGE.danger.com> In-Reply-To: <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> <200804011733.m31HXF6e039649@apollo.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> -----Original Message----- > From: Matthew Dillon [mailto:dillon@apollo.backplane.com]=20 > Sent: Tuesday, April 01, 2008 10:33 AM > To: Martin Fouts > Well, I'm not advocating a B-Tree storage model for=20 > indexing in NAND. That would be kinda nasty. What I've done=20 > is simply describe a mechanism whereby a filesystem topology=20 > is able to make use of an abstraction to > the point of being able to do away with what would=20 > normally have to be implemented by the filesystem itself. It=20 > doesn't have to be a B-Tree. >=20 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=20 > 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=20 > is wholely insufficient...=20 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=20 > 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=20 > 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,=20 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=20 > 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B95CEC1093787C4DB3655EF330984818051D17>