From owner-freebsd-geom@FreeBSD.ORG Fri Feb 15 19:00:38 2008 Return-Path: Delivered-To: geom@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 2F9E816A41A for ; Fri, 15 Feb 2008 19:00:38 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.80]) by mx1.freebsd.org (Postfix) with ESMTP id 1283B13C4F0 for ; Fri, 15 Feb 2008 19:00:37 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp007-s [10.150.69.70]) by smtpoutm.mac.com (Xserve/smtpout017/MantshX 4.0) with ESMTP id m1FIcxCQ021944 for ; Fri, 15 Feb 2008 10:38:59 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp007/MantshX 4.0) with ESMTP id m1FIcuBL026461 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Fri, 15 Feb 2008 10:38:57 -0800 (PST) Message-Id: <4A4329EB-B8EF-4CDA-98C0-4753289C4788@mac.com> From: Marcel Moolenaar To: geom@FreeBSD.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 15 Feb 2008 10:38:55 -0800 X-Mailer: Apple Mail (2.919.2) Cc: Subject: Brainstorm: NAND flash X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Feb 2008 19:00:38 -0000 All, I've been thinking about supporting NAND flash for disk storage and I've come up with some initial thoughts for people to shoot at. The intend of this thread is to align thoughts and for people to tell me that they already have an implementation ;-) NAND class ---------- NAND flash devices present themselves to the GEOM layer with GEOMs of the NAND class. This is similar to HDDs presenting themselves with GEOMs of the DISK class. The idea here is that we need some additional I/O requests and also want to be able to distinguish flash from disks. GEOMs of class NAND don't have the mediasize and sectorsize attributes (or they have them with value 0). The mediasize is dependent upon the number of bad blocks, which is not being dealt with at this level. NANDs don't have sectors. Attributes of this class include: blockcount - the raw number of blocks blocksize - the number of bytes or pages in a block pagesize - the number of bytes in a page oobsize - the number of bytes per page used for OOB The NAND class support BIO_DELETE. It'll also need something for random access to the OOB data. For this we can introduce BIO_READOOB and BIO_WRITEOOB. This allow byte-wise I/O. The standard BIO_READ and BIO_WRITE operate on pages by default. With the above, we have raw access to the NAND flash. That is before any wear-leveling or sector mapping happens. A device special file corresponding to GEOMs of this class can be used by diagnostics and/or initialization tools. Open issue: do we want this GEOM to deal with bad blocks? WEARLEVEL class --------------- GEOMs of the WEARLEVEL class (further referred to as WL class), will taste GEOMs of the NAND class. In particular, they will use the blockcount, blocksize, pagesize and oobsize in order to determine whether a GEOM is suitable. The tasting process will read OOB data to determine if wear-leveling is used. As such, wear-leveling needs to be setup. For this a geom(8) library exists. GEOMs of this class export the same variables as GEOMs of the NAND class, but also has a non-0 mediasize. The primary purpose of the WL class is to present a NAND flash device that for which wear-leveling is not a concern and that does not have any bad blocks. It can implement different policies, such as block-based wear-leveling or page-based wear-leveling. All configurable through geom(8). NANDDIDK class ------------- GEOMs of the NANDDISK class (bad name, I know) attach to GEOMs of either NAND or WEARLEVEL classes and present a consumer that looks like a "regular" disk. It has the mediasize and sectorsize attributes and not any of the blockcount, blocksize, pagesize or oobsize attributes. Also BIO_READOOB and BIO_WRITEOOB are not supported, though BIO_DELETE may be. The primary purpose of this class is to provide standard sector mapping for file systems that are not designed for NAND flash. The mapping can be trivial. NANDSIM class ------------- Not needed in production, but it would be good to have a GEOM that simulates a NAND flash and that keeps statistics. It is configured by geom(8) and needs a provider for actual storage. As such, you can use an underlying MD for storage and present the GEOM layer with a NAND flash device. Statistics include such things as erase count per block, read and write counts per block or page. Other features could include the simulation of power loss to test algorithms used for wear-leveling and or sector mapping. Let the discussion begin... -- Marcel Moolenaar xcllnt@mac.com