Re: NAND review

[Nick Garnett <nickg@ecoscentric.com>]

Andrew Lunn <andrew@lunn.ch> writes:

> We don't need to follow the disk driver approach to partitioning. As
> Ross said, he used the name "partition" because he could not think of
> a better name. However the name does not imply we need to follow the
> normal ways for partitions. All we need is a suitable API which is
> efficient when used with partitions and without partitions.

I wasn't suggesting we follow the disk driver approach. In fact I was
using it as an example of an approach that we should not use.

> 
> > I believe that an API that is partition-aware from the start is
> > preferable.
> 
> and i prefer an API which works well with and without partitions. 

Unless I have misunderstood, you appear to be criticizing the
eCosCentric design because it makes partitioning an explicit part of
the API. My point was that any API that attempts to conceal the
presence of partitions will quickly tie iteslf in knots when the need
for such things arises. I don't believe that a partition-aware API is
particularly high overhead, a handful of extra instructions per API
routine and a few extra words per data structure. With a little
judicious ifdeffery, it can be almost totally eliminated for the
single partition case.

To paraphrase Einstein: We should make an API as simple a possible,
but not simpler than it needs to be.

> Looking at the existing use cases we know about, the systems which
> don't need partitions are the ones with the most resource
> constrains. Simon does not need partitions, he plans to use a very
> lean and mean FS, and only has a small amount of ROM and RAM. With
> Ross's API there is the partitions data structure in the HAL, the code
> to get this out of the HAL and into the flash library, the extra
> function call needed to get a partition handle, and then the checks
> used to validate addresses are inside the partition. I've no idea how
> much this adds up to in terms of code and data, so i've no idea how
> big the overhead is.

My contention is that this overhead would be minimal if the NAND
system could be configured into a single partition mode. Then, a lot
of these checks get collapsed to nothing in the source, or get
optimized away by the compiler.

> If you have a dedicates partition, sized about right for the kernel,
> level wearing brings you nothing. There are no hot blocks in the
> kernel image, you replace it all every time. And how often do you
> replace the kernel? During development work, maybe quite often, but
> once the system is deployed, rarely. What is the typical life of a
> block? 10000 erases? A developer may conceivably replace the kernel
> 10,000 times, but in a deployed product i doubt this will happen. So i
> say forget about wear leveling for this case.

Exact figures for NAND reliability are hard to find. The 100,000 erase
cycle guarantee often only applies to the first block. My
understanding of NAND is that the design of the cells makes them less
reliable that NOR cells. Any cell may go bad, or read back invalid, at
any time, not just after some predefined number of erase cycles,
albeit with lower probability early in the device's lifetime. So
software must keep CRCs and handle bad blocks. The manufacturers
exploit this existing requirement to raise yield by allowing parts
with factory bad blocks to be sold to customers.

So, while most of the time you can get away with a simple approach,
every so often you will encounter a device that has cells that go bad
very quickly. Unless you have a way of working around this, you may
end up with an unusable board.

> 
> For me, dynamic partitions make sense. I'm not saying that release 1.0
> needs to have them, we just need to make sure that the design of
> release 1.0 is sufficiently flexible that adding dynamic partitions is
> just a release 1.1 feature and not a rip the guts out and start again
> for release 2.0.

I'm less convinced that dynamic partitions are necessary or useful. I
don't believe YAFFS, or any other NAND filesystem, can handle its
partition being resized or relocated and having the positions of bad
blocks change under it feet. The same would apply to any other piece
of software that was NAND aware.

Without an existing common mechanism for defining partitions in Linux,
we have to fall into line with what happens there. The majority of
drivers seem to define fixed static blocks. While we could come up
with a definition of a partitioning scheme and promote it in the Linux
world, experience suggests that this would be something of an uphill
struggle. I know people who have spent years trying to get stuff
accepted.

Your final point is exactly the one I have been trying to make. We
should not be jumping in and specifying partitioning mechanisms right
now. I think we need to gather more experience with NAND before we do
that.  Ross's design permits any sort of partioning mechanism to be
defined; at present only one, a CDL-based static partitioning, is
implemented. I also believe that by making partioning explicit in the
API, we keep the design flexible for the future.

-- 
Nick Garnett                                       eCos Kernel Architect
eCosCentric Limited    http://www.eCosCentric.com       The eCos experts
Barnwell House, Barnwell Drive, Cambridge, UK.      Tel: +44 1223 245571
Registered in England and Wales:                         Reg No: 4422071