On Mar 22, 2012, at 2:08, Dimitri Alexandris <d.alexand...@gmail.com> wrote:

> On Thu, Mar 22, 2012 at 01:39, Jim Thompson <j...@netgate.com> wrote:
>> 
>> Hmm,  No, close, but not really correct.
>> 
>> *all* flash will eventually fail if you write to it enough.  It's physics.
> 
> I do not disagree of course. Fine with theory.

Theory here is reality. 

>> SLC NAND flash is typically rated at about 100k cycles, while MLC NAND flash 
>> is typically rated at no more than 10k cycles.  Via wear-leveling and 
>> over-provisioning ('spare blocks') you can increase these numbers, but no 
>> native flash device is rated in terms of millions of erase cycles.
> 
> You are talking about theory, the memory shell. I talk about the
> actual flash disks.

I believe I mentioned controller stunts to extend the lifetime of the flash. 

> There is a specific mechanism in these industrial flashes, doing
> exactly this: When it finds an old memory shell refusing to be erased,
> it re-allocates it ("on the fly" - transparently) to a healthy / not
> used sector and marks it "bad", much like a hard disk. Read their
> documentation.

Yes, and I discussed this, but better than this is wear-leveling, which works 
to avoid the issue, rather than reacting to failure.  Combine this with some of 
the advanced error correction, and you can greatly extend the lifetime of 
(especially MLC-based) flash drives. 

Apple the same tech to SLC-based drives, and their lifetime shoots up too. 
So in the end, SLC will still win for endurance if your application does a lot 
of writes. 

The controller technology ("over provisioning") you describe is at least 2 
generations old.  It works, but its nowhere near the state of the art.

Most CF cards can do the same thing now. (it's the source of the (harmless) 
FreeBSD error with SanDisk CF cards, which report actual size, and then reserve 
some percentage of sectors for this remapping.)

> 

There are 32.5 million seconds or 8760 hours in a year.  Writing once an hour 
rather than once a second seems like an obvious way to reduce writes. 
_______________________________________________
List mailing list
List@lists.pfsense.org
http://lists.pfsense.org/mailman/listinfo/list

Reply via email to