From owner-freebsd-geom@FreeBSD.ORG Fri Feb 15 23:46:05 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 23A5E16A41B for ; Fri, 15 Feb 2008 23:46:05 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from smtpoutm.mac.com (smtpoutm.mac.com [17.148.16.73]) by mx1.freebsd.org (Postfix) with ESMTP id 1388A13C457 for ; Fri, 15 Feb 2008 23:46:04 +0000 (UTC) (envelope-from xcllnt@mac.com) Received: from mac.com (asmtp004-s [10.150.69.67]) by smtpoutm.mac.com (Xserve/smtpout010/MantshX 4.0) with ESMTP id m1FNk4pp000921; Fri, 15 Feb 2008 15:46:04 -0800 (PST) Received: from mini-g4.jnpr.net (natint3.juniper.net [66.129.224.36]) (authenticated bits=0) by mac.com (Xserve/asmtp004/MantshX 4.0) with ESMTP id m1FNk2m7001882 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 15 Feb 2008 15:46:03 -0800 (PST) Message-Id: From: Marcel Moolenaar To: Poul-Henning Kamp In-Reply-To: <93634.1203118109@critter.freebsd.dk> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v919.2) Date: Fri, 15 Feb 2008 15:46:02 -0800 References: <93634.1203118109@critter.freebsd.dk> X-Mailer: Apple Mail (2.919.2) 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:46:05 -0000 On Feb 15, 2008, at 3:28 PM, Poul-Henning Kamp wrote: > 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. The reason I thought this was good is that disks are shipped without bad blocks visible to the "application". That is: the norm is no bad blocks. With NAND flash the norm is that bad blocks part of the deal. I thought that dealing with bad blocks explicitly for NAND would level the playing field and make it more consistent... >> 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. Can't this cause race conditions? Suppose there happens to be a MBR in the first page at offset 0. The MBR class could end up taking the provider, when a wear-leveling geom should really take it. >> 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!" See above. >> 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 ? I'm ignorant of the obviousness of why sector mapping and wear-leveling are to be done at the same time... ...and I presume you can't elaborate... -- Marcel Moolenaar xcllnt@mac.com