From owner-svn-src-all@FreeBSD.ORG Tue Oct 28 15:53:04 2008 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 282BD1065683; Tue, 28 Oct 2008 15:53:04 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from harmony.bsdimp.com (bsdimp.com [199.45.160.85]) by mx1.freebsd.org (Postfix) with ESMTP id D97678FC16; Tue, 28 Oct 2008 15:53:03 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from localhost (localhost [127.0.0.1]) by harmony.bsdimp.com (8.14.2/8.14.1) with ESMTP id m9SFqj2g025717; Tue, 28 Oct 2008 09:52:45 -0600 (MDT) (envelope-from imp@bsdimp.com) Date: Tue, 28 Oct 2008 09:53:56 -0600 (MDT) Message-Id: <20081028.095356.2040345174.imp@bsdimp.com> To: stas@FreeBSD.org From: "M. Warner Losh" In-Reply-To: <20081028104435.50b3fb0f.stas@FreeBSD.org> References: <0BBCA616-4F9D-48D5-9360-CACA69480632@mac.com> <20081027.214547.709404828.imp@bsdimp.com> <20081028104435.50b3fb0f.stas@FreeBSD.org> X-Mailer: Mew version 5.2 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: svn-src-head@FreeBSD.org, svn-src-all@FreeBSD.org, xcllnt@mac.com, src-committers@FreeBSD.org Subject: Re: svn commit: r184251 - in head/sys: conf dev/cfi sys X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Oct 2008 15:53:04 -0000 In message: <20081028104435.50b3fb0f.stas@FreeBSD.org> Stanislav Sedov writes: : On Mon, 27 Oct 2008 21:45:47 -0600 (MDT) : "M. Warner Losh" mentioned: : : > : > I tend to think that we should handle the partitioning in GEOM, with : > higher level things figuring the rest out. We should expose flash, : > and its properties upstream in GEOM, but not have a separate layer for : > flash ala mdt. : > : : Yeah, GEOM is the right place for this kind of stuff, indeed. Wear levering : and similar things could be provided via GEOM too, probably. Especially if the wear averaging were optional. Then we could put 'legacy' file systems on top of the wear averaging layer, but could also develop more optimized file systems with wear averaging built in. Which one to use can also be highly application specific for the best performance. The story from the Linux world indicates that many applications just don't matter, but the ones that do often depend on a specific type of flash is used. NAND and NOR memories have very different performance characteristics, and papers presented at Linux conferences show gains for teams that have created new file systems for the specific type of flash. Right now, I expose the SPI flash as 1056 byte blocks (since that's the size of the block). A wear averaging layer would write metadata in the 32 bytes and expose 1024 or 512 byte blocks... Warner