On Mon, 10 Mar 2008, tedapt wrote:
> - maintains a buffer of serialized Java data (recent application
> state information). A file is created every few seconds and the data
> is written to this file. The previous version of this file is moved
> (renamed) as a backup in the event that the system crashes during the
> write so the earlier data can be recovered by my application.
> - a similar serialized buffer is also written to the SD card with
> lower frequency (every ten minutes) with an identical process to the
> one described above
> - three log files are written faily infrequently (ranging from
> every 10 minutes to once a day), using standard Java file I/O
> functions. These files are replaced/recreated with the old versions
> being either deleted or moved to a new filename about once a day.
You do quite a bit of renaming/moving of files. This involves a rewrites of
directory structures - if a write goes wrong in the directory who knows what
havoc can be wrought. It may be better to write/name each file once, maybe
with a timestamp in the file name and leave it to another app to get the most
recent file.
> One response (from Andrew Taylor) to my original posting suggests
> creating large files in advance for all my writes, to avoid block
> allocation. Would others agree that would reduce the risk? If so, I
> could create a pool of files to write to once, then use them for my
> various writing needs.
No it involves double writes. And the thinking behind the suggestion is
flawed. Flash disks do not work like Hard disks. Block numbers in flash
defives are virual and are mapped where necessary to real flash blocks by a
block translation table that helps with the wearlevelling. Because of this
wear levelling the all-zero block that is subsequently rewritten, will be
written to a brand new block in the most recently erased superblock of the
flash chip, and the block translation table updated to record where this block
is. So the inital zero write was a waste of time - and you flash wears out
quicker.
> Another response recommending using a Flash File System, but another
> disagreed:
>
> "I don't think you should be using Ext2/3 on Flash, you should be using
> a Flash File System, because these file systems do wear leveling so
> that erases are spread evenly across all the blocks."
>
> "...it is usually not possible to do flash file system on SD cards
> because you need access to the flash memory devices"
>
> If it is possible to use a FFS, I am perplexed (to say the least) that
> Tech. Systems would not have recommended this solution when I
> consulted with them for help. Which Flash File System would be best
> for my situation, YAFFS? Not really sure how I'd do the conversion and
> if the board supports such file systems with drivers for use with SD
> cards...
It is not possible - reread that wikipedia article.
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/ts-7000/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/ts-7000/join
(Yahoo! ID required)
<*> To change settings via email:
<*> To unsubscribe from this group, send an email to:
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
|