Re: Flash Memory Wearing Qeustions
- From: Henrik Viklund <henrik.viklund@xxxxxxxxx>
- Date: Mon, 13 Aug 2007 15:10:17 -0700
On Aug 13, 7:52 pm, S. Marsh <SMa...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:
Greetings Erik, your concerns are shared by many.
In the past I have I recommend using a commercial or open source FFS (Flash
File System) like JFFS or TrueFFS (M-Systems) because unlike FAT, these
solutions are designed to tackle this issue at its heart, and are field
proven.
In regards to wear leveling FAT/FAL block driver practically is equal
to a JFFS and TrueFFS ISPM etc. implementation. When it comes to
rigidity, it all boils down to how good the implementation for the
platform as a whole is in reality. Iv'e worked with clients that have
spent hundreds and hundreds of hours hard testing, patching up and in
the end discarding numerous "transaction safe" implementations of
TFAT, TrueFFS and ISPM file systems in search for a *truly* rock solid
file system.
With CE6, exFAT has been released and it is designed for embedded use
(as opposed to ye ol' FAT file system). How it performs in reality I
don't know yet.
Henrik Viklund
http://www.addlogic.se
The CE6 docs make reference to something called the FAL but give no details
as to its implementation and the portability of the media. I would like more
details on the FAL if anyone can provide them.
"erik.bur...@xxxxxxxxx" wrote:
Hi.
Our team is going to realize a software component running under
Windows CE 6.0 which has to record a variable amount of data:
- Synchronous data (say 200 b) every 15 minutes for a dozen of years
(with older data replaced by new one if needed).
- Asysnchronous data (not really predicatable, but for this example we
could imagine 400b per day).
Data can be asynchronously read. The target storage device is a
Samsung NAND flash memory.
We also need to persist data (and, of course, in a consistent way)
accross power failures.
We wonder about flash memory wearing issues. Currently we have
acquired this knowledge:
- Writing data on flash can be performed only to a block granularity
(128KB for our hardware). Writing smaller chunks needs to erase and
rewrite the whole block.
- There is a limited number of writings (block erase and re-write
sessions) per block before the block itslef becomes unreliable.
- FAT file systems writes the file's Directory Entry Structure each
time the file is accessed (to update the Last Access Field) [source:
http://www.maverick-os.dk/FileSystemFormats/FAT16_FileSystem.html]
- Corruption of a block can compromise each file using that block.
It seems that under these conditions the Directory Entry Structure of
the synchronous data store will be rewritten ate least 35000 times per
year, but probably twice this number because of the double update
(Last Access Date and Last Write Time). Furthermore, it's quite sure
the given structure will always reside on the same block accross its
lifetime. Also, the given structure can share the block of other
structures of files (further increasing the block wearing rate in
unpredictable ways).
Our questions are:
- Are our deductions correct?
- Is to manage the given scenery possible with "standard" Windows CE 6
components? (For example, by using different file system or by
correctly tuning a FAT?) If yes, how?
- Are there wear-leveling file systems for Windows CE? We weren't able
to find any.
- Is there a standard solution for data-acquiring devices mounting
Windows CE and storaging data on flash memory?
Thank you very much.
Erik.- Hide quoted text -
- Show quoted text -
.
- References:
- Flash Memory Wearing Qeustions
- From: erik . burigo
- RE: Flash Memory Wearing Qeustions
- From: S. Marsh
- Flash Memory Wearing Qeustions
- Prev by Date: Re: Flash Memory Wearing Qeustions
- Next by Date: Is there anyone use Spansion Nor flash?
- Previous by thread: RE: Flash Memory Wearing Qeustions
- Next by thread: Re: AllocPhysMem - data abort
- Index(es):
Relevant Pages
|
