Reliability of FLASH data storage

Reliability of FLASH data storage

[Vipin Malik]

Hi all, going through the list archive at the web site I did not find
any discussion on the reliability of data storage during writes to
FLASH.

By reliability I mean, when data is being stored onto a flash sector,
what happens when power is suddenly and without warning removed?

I am thinking of using Linux in embedded systems for future (and
current) projects. Reliable storage of data is very important in
embedded systems. More important than speed of access etc. Of course
cost is also very important- hence
the desire to use a flash file system rather than IDE flash disk (which
has its own reliability problems, as I found).

would love to hear your guys thoughts on this issue. Reading the archive
I got the impression that others are also using/thinking of using Linux
in their embedded systems.

Vipin
_______________________________________________________________________________

Daniel Industries
Houston, TX.
***All comments are my personal opinion and do not reflect the position
of my company in any way.***



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Reliability of FLASH data storage

[David Woodhouse]

vmalik@danielind.com said:
> Hi all, going through the list archive at the web site I did not find
> any discussion on the reliability of data storage during writes to
> FLASH.

You haven't thought about bit errors in read/write.

NFTL stores 6 bytes of error correction data for each 256-byte block stored on 
the flash. This can be used to correct bit errors upon reading it back.

> By reliability I mean, when data is being stored onto a flash sector,
> what happens when power is suddenly and without warning removed? 

That flash sector is invalid - it contains unknown data. The same problem 
exists with data storage on magnetic media. That's what journalling 
filesystems were invented for.

Actually, NFTL handles this situation OK - it always keeps a consistent state 
on the flash media, and only after the new block is written will it be marked 
as valid, then the old one overwritten.

But that's not enough - if you have a bog standard ext2 filesystem on your 
NFTL, then you have just reduced the problem to the same level as you'd have 
on a real disk.

You also need a filesystem which does the same - like ext3.

What I really want to do is a filesystem directly on the flash - none of this 
'pretend it's a block device' stuff.

Jason, how's FFS2 coming along? Is it possible to make it POSIX-compliant 
without a hack as evil as UMSDOS?




--
dwmw2




To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org

Re: Reliability of FLASH data storage

[Jason Gunthorpe]

On Fri, 26 Nov 1999, David Woodhouse wrote:

> What I really want to do is a filesystem directly on the flash - none of this 
> 'pretend it's a block device' stuff.
> 
> Jason, how's FFS2 coming along? Is it possible to make it POSIX-compliant 
> without a hack as evil as UMSDOS?

I'm afraid I haven't been working on that lately, back at school and no
time for it :< 

But yes, FFS2 directly on flash largely addresses this problem. There are
still some possible problems but those largely reduce down to requiring a
quick 'fsck' type pass on mount. Basicalyl with FFS2 the worst thing that
can happen is that the filesystem looses track of a block, ie you allocate
something but never link it into the filesystem strutures, this reduces
the available space in the filesystem, but does not harm the data or the
filesystem itself.

I think journaling on flash is really a rather overkill, due to the nature
of the device you can do built in journaling cheaply like FFS2 does and
not pay a space premium for a journal.

Jason



To unsubscribe, send "unsubscribe mtd" to majordomo@infradead.org