Re: Large storage options for embedded systems

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?

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

Perhaps a ram drive for logs would work as well.

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