MTD_PHRAM - what filesystem to use?

Sam Ravnborg sam at
Sun Mar 11 17:08:35 EDT 2007

On Sun, Mar 11, 2007 at 09:31:22PM +0100, Jörn Engel wrote:
> On Sun, 11 March 2007 21:05:08 +0100, Sam Ravnborg wrote:
> > 
> > At my new job we are planning to start usign a ARM9 based
> > design where we need to store data persistently.
> > 
> > Since the data are updated several times / minute the FLASH
> > devices are not suitable and therefore alternative solutions
> > are being looked at.
> > 
> > The most promising solutions semms to use battery
> > backed-up RAM.
> > >From Linux we could memorymap this area but using a filesystem
> > gives all sorts of extra bonusses so this is preferred.
> > 
> > I looked shortly at PRAMFS that seems to do the trick but PRMFS
> > seems unmaintained and not merged.
> > Then I stumbled over PHRAM.
> > I and pretty clear upon the basic parts lettign the RAM look
> > like any other FLASH device.
> > But then the question popped up.
> > 
> > What is the best filesystem to use on top of a PHRAM based
> > MTD device?
> > My first two ideas were to use either JFFS2 or ext2
> > (the latter with the blocklayer emulation).
> > But reading the documentation both looks like overkill.
> > 
> > The requirement so far is to gain maximum bebefit of the
> > avalable 100 kbytes of RAM.
> > There will be a limited number of files (< 500).
> If you decide on battery-backed RAM, the PHRAM/JFFS2 combo would be the
> best existing solution.  Alternatively you could write a custom
> filesystem.

It could be a nice challenge to write my own filesystem
just for this - on the other hand JFFS2 despite the overhead
should fulfill my demand so I will most probarly stay with that.

> With JFFS2 you should carefully decide on a suitable erasesize.  The
> JFFS2 overhead can be minimized by tuning this number.  Most likely
> something small, 4KiB or 8KiB is optimal.
> Yet another alternative would be to use flash.  The math is quite
> simple.  Example calculation:
> Update interval: 10s
> Updated data size: 10kB
> Required device lifetime: 10a
> JFFS2 overhead: 10%
> Flash durability: 100k erases
> Write rate is 10kB / 10s * 1.1 = 1.1kB/s.
> Total written data in 10a is: 1.1kB/s * 31536000s/a * 10a = 346GB
> Required flash size: 346GB / 100k = 3468kB
> So with the example numbers, you would only need a 4MiB flash chip.
> Those should be rather cheap.  But it remains your duty to redo the
> calculation with correct numbers and check for any mistakes I may have
> made.
> Also make sure that your supplier guarantees 100k erases on the flash.
> At 10k erases, you would need a device 10x bigger.  1M erases, if
> available, are even better.
Thanks again.
When I have more exact numbers I will try to redo your math.

I assume that from a performance point-of-view the FLASH based version
suffer more than the RAM one - since it is simple to 'erase' RAM.


More information about the linux-mtd mailing list