From owner-freebsd-arch@FreeBSD.ORG Mon Mar 31 20:06:30 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 6E6E21065671; Mon, 31 Mar 2008 20:06:30 +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 318988FC18; Mon, 31 Mar 2008 20:06: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 m2VK6ANu028134; Mon, 31 Mar 2008 13:06:10 -0700 (PDT) Received: (from dillon@localhost) by apollo.backplane.com (8.14.1/8.13.4/Submit) id m2VK6Aom028133; Mon, 31 Mar 2008 13:06:10 -0700 (PDT) Date: Mon, 31 Mar 2008 13:06:10 -0700 (PDT) From: Matthew Dillon Message-Id: <200803312006.m2VK6Aom028133@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> 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: Mon, 31 Mar 2008 20:06:30 -0000 :You've talked yourself into pretty much the same mistake that led to :jffs2, which turned out to be a terrible idea. I'm not familiar with jffs2 but a blockmap abstraction in of itself just doesn't have the terrible characteristics you are implying. The implementations might have been bad but the concept is quite sound. Here's a question. Ok so the best write performance is to essentially append to the NAND device. That's fairly obvious though as long as you are able to fully complete a page it doesn't really matter where the data goes. So the main issue is being able to complete a page (since you can't rewrite it). But how do you index that information? You can't simply append the information to the NAND unless you also have a way to access it. So does the filesystem have to scan the NAND (or significant portions of it) in order to build an index of the filesystem topology in system memory? No matter what you do you have to index the information *SOMEWHERE*. That somewhere is either going to be in-NAND or in-memory or some combination of the two. If it is entirely in-memory you have to scan the auxillary information in nearly the entire NAND array to build your index. If it is entirely in-NAND you have a significant updating problem. A named-block model, done right, can serve as the index. That is, it is exactly the same problem just viewed from a different angle. A named-block model does not necessarily imply that the indexing topology has to be stored entirely in-NAND, it does not imply any sort of linear array, and it does not imply any random-updating requirement. I don't know what the jffs2 folks did but you shouldn't take their performance failure as an indication that the general concept is incorrect. -Matt