Writing frequently to NAND - wearing, caching?

Writing frequently to NAND - wearing, caching?

[Martin Egholm Nielsen]

Hi there,

I have an application which may need to write states frequently to my 
nand-fs in order to have these states in case of powerdown.
But I'm a bit concerned about wearing the nand if I write to frequently.

So, if I only need to write, say, 100 bytes every second, how often will 
this actually be flushed to the nand?
Is there a maximum commit/flush frequency built in the driver? Or can 
this be configured?
I know this is a very diffuse question, but hopefully you get my drift.

BR,
  Martin Egholm

Re: Writing frequently to NAND - wearing, caching?

[Charles Manning]

On Thursday 03 February 2005 22:31, Martin Egholm Nielsen wrote:
> Hi there,
>
> I have an application which may need to write states frequently to my
> nand-fs in order to have these states in case of powerdown.
> But I'm a bit concerned about wearing the nand if I write to frequently.
>
> So, if I only need to write, say, 100 bytes every second, how often will
> this actually be flushed to the nand?
> Is there a maximum commit/flush frequency built in the driver? Or can
> this be configured?
> I know this is a very diffuse question, but hopefully you get my drift.
>
> BR,
>   Martin Egholm

It depends on what fs you're using.

With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash 
"wearing out".  I have done accelerated lifetime tests on NAND using YAFFS 
and in one test wrote 130GB to NAND without any data loss, bad blocks 
happening etc.

The NAND writes whenever the file system tells it to, so again your question 
is FS dependent, but all file systems that are NAND-friendly should handle 
the load you mention with no problems.

-- Charles

Re: Writing frequently to NAND - wearing, caching?

[Martin Egholm Nielsen]

Hi,

>>I have an application which may need to write states frequently to my
>>nand-fs in order to have these states in case of powerdown.
>>But I'm a bit concerned about wearing the nand if I write to frequently.

>>So, if I only need to write, say, 100 bytes every second, how often will
>>this actually be flushed to the nand?
>>Is there a maximum commit/flush frequency built in the driver? Or can
>>this be configured?

> It depends on what fs you're using.
> With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash 
> "wearing out".  I have done accelerated lifetime tests on NAND using YAFFS 
> and in one test wrote 130GB to NAND without any data loss, bad blocks 
> happening etc.
Now, that's a lot :-)
I'm using JFFS2 - so hopefully you're right...

> The NAND writes whenever the file system tells it to, so again your question 
> is FS dependent, but all file systems that are NAND-friendly should handle 
> the load you mention with no problems.
And that is JFFS2 - but since it's a journaling fs it must commit the 
journal, as well, every now and then...

// Martin

Re: Writing frequently to NAND - wearing, caching?

[Estelle HAMMACHE]

Hi Martin,

regarding JFFS2/NAND, the filesystem does not cache
write operations, however there is a NAND page cache.
This means that if you write 100 bytes at a time,
you will not use a full NAND page each time, but you will
probably create two JFFS2 data nodes in the same
NAND flash page. (NB a node may overlap a page boundary,
the page buffer is flushed to the device when
it is full).
Now if you do fsync between each write operation,
the page buffer will be flushed immediately. So in
this case you do use a full page (256 bytes or 2KB)
for each write.
The main drawback of JFFS2 in both cases is that
you end up with many small nodes on the flash
and this slows down initialization and access to this
file (see thread "jffs2_get_inode_nodes() very very slow"
in the February archive at 
http://lists.infradead.org/mailman/listinfo/linux-mtd/).
If you were to write 1 byte at a time this problem would
be even more acute. 
There is no "journal" per se in JFFS2, the whole 
filesystem is log-based.

The case with fsync will wear up the flash somewhat faster
but in any case JFFS2 contains integrated wear levelling
which will distribute the wear on all the blocks in the
partition, so no single block should be worn so much
that it fails (ideally. In real life some NAND blocks
may fail at any time even with perfect wear levelling.
However JFFS2 is able to cope with this case, and the
failed write operation will be retried on another block).

Have you read the JFFS/JFFS2 paper at
http://sources.redhat.com/jffs2/jffs2.pdf ?
(it is slightly out of date but the basic principles
of journaling, wear leveling, data nodes etc have not 
changed).

bye
Estelle


Martin Egholm Nielsen wrote:
> 
> Hi,
> 
> >>I have an application which may need to write states frequently to my
> >>nand-fs in order to have these states in case of powerdown.
> >>But I'm a bit concerned about wearing the nand if I write to frequently.
> 
> >>So, if I only need to write, say, 100 bytes every second, how often will
> >>this actually be flushed to the nand?
> >>Is there a maximum commit/flush frequency built in the driver? Or can
> >>this be configured?
> 
> > It depends on what fs you're using.
> > With YAFFS, and I believe JFFS2 too, there is no reason to worry about flash
> > "wearing out".  I have done accelerated lifetime tests on NAND using YAFFS
> > and in one test wrote 130GB to NAND without any data loss, bad blocks
> > happening etc.
> Now, that's a lot :-)
> I'm using JFFS2 - so hopefully you're right...
> 
> > The NAND writes whenever the file system tells it to, so again your question
> > is FS dependent, but all file systems that are NAND-friendly should handle
> > the load you mention with no problems.
> And that is JFFS2 - but since it's a journaling fs it must commit the
> journal, as well, every now and then...
> 
> // Martin
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/

Re: Writing frequently to NAND - wearing, caching?

[Charles Manning]

On Monday 07 February 2005 21:33, Martin Egholm Nielsen wrote:
> Hi,
>
> >>I have an application which may need to write states frequently to my
> >>nand-fs in order to have these states in case of powerdown.
> >>But I'm a bit concerned about wearing the nand if I write to frequently.
> >>
> >>So, if I only need to write, say, 100 bytes every second, how often will
> >>this actually be flushed to the nand?
> >>Is there a maximum commit/flush frequency built in the driver? Or can
> >>this be configured?
> >
> > It depends on what fs you're using.
> > With YAFFS, and I believe JFFS2 too, there is no reason to worry about
> > flash "wearing out".  I have done accelerated lifetime tests on NAND
> > using YAFFS and in one test wrote 130GB to NAND without any data loss,
> > bad blocks happening etc.
>
> Now, that's a lot :-)
> I'm using JFFS2 - so hopefully you're right...

What I always do is to do some lifetime estimates for stuff that can wear 
out. For most handheld mobile stuff this means flash, batteries, backlights.

For instance, YAFFS was used in a  hand-held data logger/PDA-thing 
application. 
*Typical high usage for a full day: 5MB of writes. Double it 10MB
*Typical high usage per year: 100 days/year. Use 150 days.
*Typical product lifetime: 5 years. Use 10 years.

Double again for all garbage collection etc.

That works out to 30GB of writing. 

On a 128Mbyte NAND, that works out at an average of 240 writes for each part 
of flash. Even if we go multiply by a very large "skew factor" of 100  
(because we're not using explicite wear levelling) we still have only reached 
24,000 - only 24% of the 100,000 cycle lifetime of the flash.

I did the 130GB test because I wanted a big enough number (~50 typical  
lifetimes) to make the nay-sayers shut up forever.

>
> > The NAND writes whenever the file system tells it to, so again your
> > question is FS dependent, but all file systems that are NAND-friendly
> > should handle the load you mention with no problems.
>
> And that is JFFS2 - but since it's a journaling fs it must commit the
> journal, as well, every now and then...

YAFFS and JFFS2 are both what I would consider to be very flash friendly. 
Even FAT on a SmartMedia is not too bad.  FAT+SM corruyptions are generally 
the fault of general FAT crappiness.

SmartMedia cycles through the blocks in the free pool. On a device with, say, 
1024 blocks, only 1000, say, of these will be used. The other are either bad 
blocks or in the free pool. When SmartMedia writes a block it uses a block 
from the free pool, then releases the old block to the free pool. This 
implements a degree of "implcite" wear levelling (ie. this use of a free pool 
tends to cause wear levelling as a side effect).

Where you'd get problem would be using a file system like FAT without a 
logical to physical remapping layer. This would result in the 
blocks holding the FAT getting hammered hard. 

Wear levelling, with a reasonable file system or logical mapping layer, is 
just a non-issue for most products.

-- Charles

Re: Writing frequently to NAND - wearing, caching?

[Aras Vaichas]

Charles Manning wrote:
> On Monday 07 February 2005 21:33, Martin Egholm Nielsen wrote:
> 
>>Hi,
>>
>>
>>>>I have an application which may need to write states frequently to my
>>>>nand-fs in order to have these states in case of powerdown.
>>>>But I'm a bit concerned about wearing the nand if I write to frequently.
 > <snip>
> (because we're not using explicite wear levelling) we still have only reached 
> 24,000 - only 24% of the 100,000 cycle lifetime of the flash.
> 

... and then there is the fact that the 100,000 write cycle limit is generally 
a conservative estimate based on testing of the device at an operating 
temperature of around 125 celcius! Most likely the device will be able to 
withstand over to 1,000,000 write cycles before failure. If your FS uses write 
verification to make sure the data is secure then you shouldn't have any 
problems even if you do reach this limit on some areas of the Flash.

 From the "Toshiba NAND Flash Applications Design Guide"

"NOR Flash is typically limited to around 100,000 cycles. Since the electron 
flow-path due to the hot electron injection for programming is different from 
the one due to tunneling from the floating gate to the source for erasing, 
degradation is enhanced. However, in NAND Flash, both the programming and 
erasing is achieved by uniform Fowler- Nordheim tunneling between the floating 
gate and the substrate. This uniform programming and uniform erasing technology 
guarantees a wide cell threshold window even after 1,000,000 cycles."

and

"There is one question that often comes up  Is ECC really necessary?  After 
all, the likeliest cause of a bit error is during the programming process. For 
example, if you program a block, then verify it has no errors, how reliable is 
the data? In these ROM-like applications where the write/erase cycles is very 
low, the actual failure rate for a block is about 3 ppm after 10 years (i.e. 3 
blocks out of every million blocks will have a bit error after 10 years) in 
which a block failure is defined as a single bit error. This result was derived 
from testing 29708 pieces of 512Mb NAND (0.16um) by writing a checkerboard 
pattern into blocks and storing at 125C. Since there will be a non-zero data 
retention failure rate, you should limit the amount of code to 1 block to 
achieve a low ppm probability of failure."


regards,

Aras

Re: Writing frequently to NAND - wearing, caching?

[Martin Egholm Nielsen]

Hi Aras,

>>>>> I have an application which may need to write states frequently to my
>>>>> nand-fs in order to have these states in case of powerdown.
>>>>> But I'm a bit concerned about wearing the nand if I write to 
>>>>> frequently.
>  > <snip>
>> (because we're not using explicite wear levelling) we still have only 
>> reached 24,000 - only 24% of the 100,000 cycle lifetime of the flash.
Thanks for the "comments" below - they are nice to have...

> ... and then there is the fact that the 100,000 write cycle limit is 
> generally a conservative estimate based on testing of the device at an 
> operating temperature of around 125 celcius! Most likely the device will 
> be able to withstand over to 1,000,000 write cycles before failure. If 
> your FS uses write verification to make sure the data is secure then you 
> shouldn't have any problems even if you do reach this limit on some 
> areas of the Flash.
> 
>  From the "Toshiba NAND Flash Applications Design Guide"
> 
> "NOR Flash is typically limited to around 100,000 cycles. Since the 
> electron flow-path due to the hot electron injection for programming is 
> different from the one due to tunneling from the floating gate to the 
> source for erasing, degradation is enhanced. However, in NAND Flash, 
> both the programming and erasing is achieved by uniform Fowler- Nordheim 
> tunneling between the floating gate and the substrate. This uniform 
> programming and uniform erasing technology guarantees a wide cell 
> threshold window even after 1,000,000 cycles."
> 
> and
> 
> "There is one question that often comes up  Is ECC really necessary?  
> After all, the likeliest cause of a bit error is during the programming 
> process. For example, if you program a block, then verify it has no 
> errors, how reliable is the data? In these ROM-like applications where 
> the write/erase cycles is very low, the actual failure rate for a block 
> is about 3 ppm after 10 years (i.e. 3 blocks out of every million blocks 
> will have a bit error after 10 years) in which a block failure is 
> defined as a single bit error. This result was derived from testing 
> 29708 pieces of 512Mb NAND (0.16um) by writing a checkerboard pattern 
> into blocks and storing at 125C. Since there will be a non-zero data 
> retention failure rate, you should limit the amount of code to 1 block 
> to achieve a low ppm probability of failure."