Reliability of FLASH data storage
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 [email protected]
Quoted 3 lines · [email protected] 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.
Quoted 2 lines
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 [email protected]
Quoted 5 lines · David Woodhouse
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 [email protected]