From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 17:56:16 2008 Return-Path: Delivered-To: arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B755E1065672; Tue, 1 Apr 2008 17:56:16 +0000 (UTC) (envelope-from mfouts@danger.com) Received: from mx.danger.com (wall.danger.com [216.220.212.140]) by mx1.freebsd.org (Postfix) with ESMTP id 987C68FC2D; Tue, 1 Apr 2008 17:56:16 +0000 (UTC) (envelope-from mfouts@danger.com) Received: from danger.com (exchange3.danger.com [10.0.1.7]) by mx.danger.com (Postfix) with ESMTP id 595724020D7; Tue, 1 Apr 2008 10:56:06 -0700 (PDT) X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Tue, 1 Apr 2008 10:56:14 -0700 Message-ID: In-Reply-To: <200804011733.m31HXF6e039649@apollo.backplane.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Flash disks and FFS layout heuristics Thread-Index: AciUHoB86TsNjwfyS+ixG2NdJB9SywAACYKg References: <20080330231544.A96475@localhost> <200803310135.m2V1ZpiN018354@apollo.backplane.com> <200803312125.29325.qpadla@gmail.com> <200803311915.m2VJFSoR027593@apollo.backplane.com> <200803312006.m2VK6Aom028133@apollo.backplane.com> <200803312254.m2VMsPqZ029549@apollo.backplane.com> <200804011733.m31HXF6e039649@apollo.backplane.com> From: "Martin Fouts" To: "Matthew Dillon" Cc: Christopher Arnold , arch@freebsd.org, qpadla@gmail.com, freebsd-arch@freebsd.org Subject: RE: Flash disks and FFS layout heuristics X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2008 17:56:16 -0000 > -----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.