[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Q: JFFS2 RAM requirements (and other questions...)



On Sat, 2004-07-03 at 15:41 +0200, Nitzan Shaked wrote:
> Hello
> 
> I am considering to use JFFS2 in my embedded system, and was hoping you
> could save me a week's worth of trouble by answering some order-0 questions:
> 
> 1) I have read the PDF and other introductry material, and I understand that
> for each file a list of nodes in maintained in RAM. For a 32MB file-system
> containing "your average stuff" (MP3, MIDI, JPG, no code) -- what would you
> say is the RAM requirement ? Is there a way to bound this number?

It's not so useful to give a theoretical upper bound. That would be the
degenerate case where you wrote all the files in single-byte chunks, so
each byte of data has a 68-byte node header on the medium, and a 16-byte
'struct jffs2_raw_node_ref' in RAM. In practice, that would get
garbage-collected and the data would tend to get coalesced into 4KiB
chunks.

You can try this on Linux. Make a 'mtdram' device of the appropriate
size and eraseblock size, fill it with your sample workload. Look in
/proc/slabinfo to see how many of the JFFS2 data structures are present.

The jffs2_raw_node_ref is the one which is present at all times while
the file system is mounted. jffs2_full_* are present only when files are
being used (well, actually when they're in the inode cache in Linux). 

> 2) Linux- and NAND support: I understand that under the linux-mtd NAND
> support is not finalized ("nearing production quality"). Still, my system
> does not use linux at all. If I use JFFS2 it will be on a proprietary RTOS
> kernel (no processes, just "threads"), and I will need to port it. So:
> 2.1) Has this been done before?

Not for NAND. JFFS2 on NOR is already working on eCos -- the Linuxisms
in the original code have already been eliminated.

If looking at the eCos code for inspiration though -- be aware that much
of it predates the cleaning up of the core JFFS2 code, so it looks a
_lot_ more like a 'Linux VFS emulation layer' code than it now needs to.
I've gone through it doing things like changing 'struct inode' to
'struct _inode' to make the point that it's not the same as Linux and no
longer used by core code, but nobody on the eCos side has yet cleaned it
up.

> 2.2) Given that I do not use Linux -- how hard will it be to add NAND
> support?

The NAND support isn't used on eCos yet. There's a tighter coupling
between JFFS2 and the OS flash drivers for NAND, because of details
about how we handle bad blocks, the spare area, etc. But NAND support
shouldn't be _too_ hard to extend to non-Linux platforms.

-- 
dwmw2



To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to majordomo@xxxxxxx.com