Date: Fri, 15 Feb 2008 15:46:02 -0800 From: Marcel Moolenaar <xcllnt@mac.com> To: Poul-Henning Kamp <phk@phk.freebsd.dk> Cc: geom@FreeBSD.org Subject: Re: Brainstorm: NAND flash Message-ID: <A7D3ED75-BC10-4E15-BABE-7182995FAC61@mac.com> In-Reply-To: <93634.1203118109@critter.freebsd.dk> References: <93634.1203118109@critter.freebsd.dk>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?A7D3ED75-BC10-4E15-BABE-7182995FAC61>