From owner-freebsd-arch@FreeBSD.ORG Tue Apr 1 17:33:31 2008 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 1469C106566B; Tue, 1 Apr 2008 17:33:31 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (apollo.backplane.com [216.240.41.2]) by mx1.freebsd.org (Postfix) with ESMTP id D624D8FC15; Tue, 1 Apr 2008 17:33:30 +0000 (UTC) (envelope-from dillon@apollo.backplane.com) Received: from apollo.backplane.com (localhost [127.0.0.1]) by apollo.backplane.com (8.14.1/8.14.1) with ESMTP id m31HXFaJ039652; Tue, 1 Apr 2008 10:33:15 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m31HXF6e039649; Tue, 1 Apr 2008 10:33:15 -0700 (PDT) Date: Tue, 1 Apr 2008 10:33:15 -0700 (PDT) From: Matthew Dillon Message-Id: <200804011733.m31HXF6e039649@apollo.backplane.com> To: "Martin Fouts" 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> 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:33:31 -0000 :> 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