Alf Katz <[EMAIL PROTECTED]> writes:
> Does anybody out there know of any tests performed on Disk On Chip devices
> to determine whether or not there are any problems with memory loss when
> cycling power. We've set up a test where we allow an Advantech card with a
> DOC to power up for a random time (0 to 4 minutes), and are getting
> corrupted files.
Are you using ext2fs? Use chattr to set the +S attribute on the files
you change, so they flush through to disk as they are written. You'll
be amazed how painfully this impacts performance. You'll also get
killed by inode access time updates, so use the chattr +A flag also,
and know that support for it isn't in the 2.0 series kernels (not sure
when it appears, actually).
The only way to use these things safely under Linux, to my knowledge,
is mounted read-only.
I've ranted repeatedly (though not recently) about the need for (1)
raw kernel access to flash chips (not interface-laced "flash disks"),
and (2) an appropriate kernel filesystem built on top of these raw
chips, perhaps a log filesystem (which stores writes as a list of
changes to files, instead of trying to overwrite the files
themselves). This is both a hardware problem -- I don't know of
commercial single-board computers that offer more than about 1M of
raw flash chips -- and a software problem, solved by writing software.
I'd be happy to outline my previous rants on request.
The DOC things claim to do wear leveling and such by abstracting the
raw chips -- when you write to a "location", the interface (probably
implemented in the binary-only kernel driver, but maybe partly in
hardware) maps the logical "location" to a physical chip address based
on its own idea of how it should be done. You and I, mere mortals,
aren't privy to the details of this mapping, so we can't know whether
it works well with non-MSDOS filesystems. I'd bet there are
half-a-dozen assumptions built into the interface that aren't valid
for ext2fs -- I'm safe in offering that bet because the only people
who might be able to disprove it are committed to keeping the
necessary details to themselves.
--
steven Work
Renaissance Labs
[EMAIL PROTECTED]
360 647-1833
