On Aug 18, 2006, at 1:13 PM, rockwell618@... wrote:
> I have an application running on a standalone basix 400-bt that
> needs to record its activties in log files, which currently reside
> on flash. (By standalone I mean it is not connected to a network.)
> On average it logs an 80 char line every 30 secs or so.
> Periodically the log files are uploaded to another host where they
> are statistically analyzed.
>
> My question concerns program/erasure fatigue, which I presume is an
> inherent and unavoidable property of Strataflash. I don't know the
> advertized durability of the gumstix Strataflash (1M program/
> erasure cycles per block??) nor do I have a handle on the
> relationship between an app-level fprintf statement and the
> underlying block-level program/erasure operations. But I do think
> this is something to be concerned about -- hopefully I am wrong.
>
> Is data logging indeed something that should be avoided on the
> gumstix? Is there a practical method of calculating the life of
> the gumstix flash given a known logging level? What are reasonable
> alternatives to flash-resident log files for non-networked
> gumstix: is RS-MMC the only answer?
The datasheet for the J3 strataflash we use says: "100K Minimum erase
cycles per block"
The JFFS2 filesystem does wear-levelling fairly well, so if it will
spread writes around all of flash nicely. I think the compression
part of JFFS2 will greatly prefer larger writes to smaller ones
though, so if you're writing 80-byte chunks, you might do well to
write them first to /tmp aggregate a few and then write a bigger
chunk to flash after a while. If you absolutely can't afford to lost
any messages due to power outage, then you should still be just fine
though writing 80 bytes at a time. I'm not sure how fprintf is
implemented in uclibc, but you might be better off doing a sprintf
and then write() so that you can be more sure that the I/O will just
be done in one chunk at the low-level. fprintf might write a byte at
a time instead, which would probably not be well-regarded by JFFS2.
I think if you google about, you'll be able to find some JFFS2
patches which track the number of erase cycles for each block in the
block headers, which would allow you to run some tests to dynamically
determine how the wear levelling is working for you, and from that
you could likely estimate lifetime based on the "100K minimum" standard.
C
|