Re: Large storage options for embedded systems

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
Quoted text here. Click to load it

CF 'generally' does sector remapping so that even if you write one sector
again and again you will evenly wear the whole flash. You can also get 1gb
(and I think 2gb CF now).

Why would be constantly writing one sector?


Ralph



Re: Large storage options for embedded systems
Quoted text here. Click to load it

log files, wtmp etc are constantly written to in unix in small
increments. I suppose that problem is rerouted by turning off all
logs and the likes, and I believe one filesystem type in Linux
distributes small writes across sectors somehow.

Do you think CF or other flash chips are reasonably priced at 1GB, to
beat say the microdrive? And the approximate cost of just ROM chips of
the same size?

Re: Large storage options for embedded systems

Quoted text here. Click to load it

I think you may be thinking of JFS.

Because of the automatic remapping I spoke about with CF, JFS isn't a good
choice for that.

There have been plenty of threads on this lately in here.

Ralph



Re: Large storage options for embedded systems
Perhaps a ram drive for logs would work as well.

Quoted text here. Click to load it



Re: Large storage options for embedded systems
On 7 Jul 2003 18:12:54 -0700, snipped-for-privacy@ghazan.haider.name (Ghazan

Quoted text here. Click to load it

I think you misunderstand the limits of flash. The life problem is due
to the erase cycle. A block can only be erased a limited number of
times, estimated at 100,000 to 1,000,000 in modern chips. Once erased,
you can append as many pieces into the block as you wish until it is
full. Then, until you move or delete it, the content is static. Wear
leveling simply uses a different block each time it needs a new sector
to write, so that it isn't erasing the same block all the time.

Someone else mentioned JFFS, which is optimised for flash. I believe
it operates without i-nodes or a true directory, to minimize the erase
cycles related to those clusters. The disadvantage is that it has to
build the directory in RAM from the journal entries each time the
system boots up.

Bob McConnell
N2SPP


Site Timeline