Subject: Re: MTD devices in NetBSD
To: Terry Moore <email@example.com>
From: Garrett D'Amore <firstname.lastname@example.org>
Date: 03/23/2006 11:45:04
Terry Moore wrote:
> Depending on the media, writing a block even twice can cause non-local
> errors. This is a major issue when working with NAND flash. The chip
> spec says you can write 10 times before erasing, but in practice
> (i.e., I have some personal experience in this area) writing more than
> once makes the error rate unacceptable for the next layer up, even if
> you have ECC at the next layer, because of the nature of the failures,
> and practical details such as the difficulty of testing a large
> NAND-flash device on production testers (you need the ECC for
> recovering from manufacturing flaws -- you don't want to waste it on
> recovering from flaws induced by writing a block more than once).
> My advice is, unless you can enlist a NAND flash expert in the quest:
> start with NOR flash, and don't expect your NOR flash technology to be
> your solution for NAND. Definitely don't reason from anything you
> know about NOR flash to NAND flash, you really need to forget all that
> when working with NAND.
Okay, thanks for the warnings.
However, if there is some obvious thing I can do which will make it
easier for NAND to make use of the same framework, then I'd rather do
that, than go in a different direction that precludes it entirely.
The fact that writing media twice before erase can cause errors is
substantive. It suggests that at a minimum, a block oriented approach
to NAND is going to work *even* less well than it would for NOR. So to
me it underscores my point, which is that details about the underlying
devices need to be exposed to a filesystem, rather than hidden from it.
Btw, this doesn't guarantee that what I do will be useful/usable for
NAND later, but it certainly improves the odds. So I don't want to
ignore NAND completely. Unless NAND is so totally different from NOR
that there is no sane common abstraction. I *think* the existence of
the MTD framework in Linux is evidence that the notion that the
abstractions have *something* in common is not totally insane.
> Also, this is an area where the giants have all kinds of patents, so
> one must be careful, or judgement-proof. (This is the reason my
> company files for patents, more or less in self-defense.)
> At 06:06 PM 3/23/2006 +0000, David Brownlee wrote:
>> On Thu, 23 Mar 2006, Charles M. Hannum wrote:
>>> On Wed, Mar 22, 2006 at 06:45:08PM +0000, David Brownlee wrote:
>>>> From a hardware perspective you should be able to perform
>>>> sub-block writes down to the word level. A perfect example
>>>> of that usage would be a an app performing synchronous
>>>> appending writes to a logfile. Providing you are not
>>>> _clearing_ any bit in the current block you can just 'write
>>>> over' the current values (assuming standard flash).
>>> Unfortunately, current file systems like FFS can't do this, because
>>> zero all the unused data in a block, and rewrite it every time.
>>> This is
>>> a good example of why a flash-aware file system is important -- you can
>>> save a lot of wear, and gain a lot performance here.
>> Presumably that could be handled by having the layer
>> underneath the filesystem test if a write only sets bits
>> in an existing block, and if so just go ahead and 'overwrite'
>> that block. It still doesn't make existing filesystems a good
>> fit to flash devices...
>> David/absolute -- www.NetBSD.org: No hype
>> required --
Garrett D'Amore, Principal Software Engineer
Tadpole Computer / Computing Technologies Division,
General Dynamics C4 Systems
Phone: 951 325-2134 Fax: 951 325-2191