Couple ideas for custom jffs2 build

[Jared Hulbert]

We are attempting to reduce RAM consumption of jffs2 for a specific
customer with a specific use case in mind.  One idea is to hack it to
merge jffs2_full_dnode and jffs3_node_frag.  From a high level I can
see this would make every write a full dnode replace.  But for
multimedia file storage this is not so bad.  I'm assume this _could_
be done without _too_ much effort, it feels naive to me though.  How
bad is this?

The second issue is a 20s delay in open()ing a 30MB file.  We believe,
having looked at /proc/slabinfo, this is caused by  the system having
to read in all the jffs2_node_frags.  Wouldn't it be _easy_ to put a
blocks raw jffs2_node_frags in the eraseblock summary and sort through
them at boot?