From owner-freebsd-geom@FreeBSD.ORG Fri Feb 15 23:48:21 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 9D7AB16A417 for ; Fri, 15 Feb 2008 23:48:21 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from phk.freebsd.dk (phk.freebsd.dk [130.225.244.222]) by mx1.freebsd.org (Postfix) with ESMTP id 63C7013C4E3 for ; Fri, 15 Feb 2008 23:48:20 +0000 (UTC) (envelope-from phk@critter.freebsd.dk) Received: from critter.freebsd.dk (unknown [192.168.61.3]) by phk.freebsd.dk (Postfix) with ESMTP id 34EC217104; Fri, 15 Feb 2008 23:28:30 +0000 (UTC) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.14.2/8.14.2) with ESMTP id m1FNSTXj093635; Fri, 15 Feb 2008 23:28:29 GMT (envelope-from phk@critter.freebsd.dk) To: Marcel Moolenaar From: "Poul-Henning Kamp" In-Reply-To: Your message of "Fri, 15 Feb 2008 10:38:55 PST." <4A4329EB-B8EF-4CDA-98C0-4753289C4788@mac.com> Date: Fri, 15 Feb 2008 23:28:29 +0000 Message-ID: <93634.1203118109@critter.freebsd.dk> Sender: phk@critter.freebsd.dk Cc: geom@FreeBSD.org Subject: Re: 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 23:48:21 -0000 In message <4A4329EB-B8EF-4CDA-98C0-4753289C4788@mac.com>, Marcel Moolenaar wri tes: >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. Mediasize is about addressability, not about usability, so this assumption is wrong. A GEOM provider is just an addressable array of sectors, it doesn't guarantee that you can read them all or write them all, as is indeed the case when your disk develops a bad sector. NAND is only special due to the OOB stuff, the main page array is just a pretty spotty disk, for all GEOM cares. >dealt with at this level. NANDs don't have sectors. >Attributes of this class include: > blockcount - the raw number of blocks This goes in mediasize (as a byte count) > blocksize - the number of bytes or pages in a block This goes in sectorsize. > pagesize - the number of bytes in a page > oobsize - the number of bytes per page used for OOB These two are secondary attributes which are not likely to change easily for a given NAND, so they should be handled by the BIO_GETATTR (as "NAND::PAGESIZE" and "NAND::OOBSIZE" for instance). >For this we can introduce >BIO_READOOB and BIO_WRITEOOB. Yes, this sound sensible. The original plan is that all BIO_ operations are power of two and providers should have a bitmap of which they support, (G_PF_CANDELETE is a mistake in this respect) so this shouldn't be a problem. In general we should not introduce new BIO_ operations without reason, but these two are very reasonable. >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. Yes, given suitable ioctls to geom_dev, for the new BIO_*OOB. >Open issue: do we want this GEOM to deal with bad blocks? I'm not sure I understand this question. GEOM doesn't know about bad blocks, if you try to use them, GEOM happily transports the resulting error code back, but it does not care if the error code is "read error" or "values of beta gives rise to dom!" >WEARLEVEL class >--------------- Sounds good. I'm under NDA on M-Systems algorithm and Sandisk is sueing left and right on those patents. >NANDDIDK class >------------- >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. I don't understand why this would be necessary, this is normally done in the wearleveling class (for reasons that should be obvious), so why do you want to split it into a separate class ? >NANDSIM class >------------- > >Not needed in production, but it would be good to have a GEOM >that simulates a NAND flash and that keeps statistics. A very good idea. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence.