Re: Throughput question with CF/DiskOnChip

From: jro (john_at_jrobot.net)
Date: 01/02/05 

Date: 1 Jan 2005 17:37:29 -0800

Michael Schnell wrote:
> A CF can't be used for that at all unless you can make absolutely
sure
> that power is always provided to the system until -say- a minute
after
> the last write action. The internals of a CF sometimes need some
> absolutely undetermined time after the start of a write request. If
> power is removed within this time the card may be damaged and
unusable.

Hmmm...I have not read about this. Of course I can understand the
possibility of losing a portion of a file that is in the process of
being flushed to disk if the CF is removed with the write in progress
(and this is an acceptable constraint for this particular application).
However, I don't understand how the CF card could be damaged and made
unusable if it is removed at the wrong time. My PDA has a CF card, and
it has no knowledge of when I would remove the CF card...but I can
remove the card whenever I want. How does it solve this problem?
>
> A DOC should not be accessed with an EXT2 file system. this will
cause
> wear out effects and damage part of the storage cells very soon and
make
> the data unusable and the system unwritable.

The ext2 files system on top of the DiskOnChip appears to be a fairly
common activity:

http://www.rtd.com/NEW_appnote/SWM-640000017%20rev%20A.pdf
http://www.gctglobal.com/Download/DiskOnChip/diskonchip.html
http://www.denx.de/twiki/bin/view/DULG/DiskOnChip

Why exactly do you discourage this activity?

>
> Hopefully the DOC is just a Flash array accessible in memory blocks
with
> no internal intelligence.

The DOC has a considerable on-board intelligence.
>
> If so, you can use a special Flash file system (e.g. JFF or JFF2) on
an
> appropriate flash media driver.
IIRC, JFFS2 was in the works for supporting the DOC, but at the time
the system was being developed it was not ready yet. So we passed on
it...it could be considered again if there were a problem with this.
We have been using the DOC with ext2 as is for the last year or so, and
doing variable throughput usage scenarios (scaling from a few Kbits/sec
all the way up to the full 176 Kbits/sec), and we haven't seen the
device fail (unless, of course, the "blip" we are seeing is due to the
number of bad blocks increasing, and thus the DOC driver/hardware
taking longer and longer to find valid flash blocks to write to).

>
> Same should take care of wear out effects and supposedly will not do
the
> write buffering that causes the said "blip".
Thanks for the insight...I'll be curious to hear your response to the
above questions....any other ideas from anyone for the original
questions?

>
> -Michael

Relevant Pages