Thanks for the responses. Some more background on my situation: I'm
running Debian from a 5e12MB SD card on a TS-7260 mounted as an ext3
filesystem. My application is a Java application, using JamVM as the
Java implementation. My application performs writes to the SD card in
several different processes:
- 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.
The SD card is mounted by an initrd image during the bootup process by
a linuxrc script. The mount is done with options noatime, async and
default "ordered" level for the ext3 filesystem. Linuxrc then does a
pivot_root to the newly mounted SD card's Debian filesystem. I built
the kernel from Tech. Systems kernel code using the journaling option
to get the ext3 driver support.
Engineers at Tech. Systems tell me that the async mount option is
safe, though I wonder if the sync option would provide me with better
protection?
I've found this rather alarming article on wikipedia which addresses
the instability of the ext3 filesystem, specifically the section
titled "No checksumming in journal" and the equally frightening
footnotes 13 and 14 which are noted in it:
http://en.wikipedia.org/wiki/Ext3#No_checksumming_in_journal. Tech.
Systems tells me that they don't do "out-of-order" write caching,
though I still wonder if this is related to the async vs. sync options
in the mount options.
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.
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...
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/
|