JFFS3 and RAM consumprion reincarnated
joern at wohnheim.fh-wedel.de
Wed Mar 2 09:44:07 EST 2005
On Tue, 1 March 2005 16:28:36 +0000, Artem B. Bityuckiy wrote:
> We've stopped on the design like this: each inode has ICP which is stored
> on flash. The ICP is being outdated by GC and users. Since it is
> inefficient to rewrite new inode every time, we won't rewrite it but add
> node_ref instead. Sometimes we'll flush ICP and free node_refs.
I agree with tglx, your approach is complicated (aka horrible). How
about something much simpler:
o The ICP is just a list of erase blocks.
o For any non-obsolete node belonging to an inode, the containing
erase block number *must* be part of ICP.
o If an erase block doesn't contain non-obsolute nodes for this inode,
its number *should* not be part of ICP.
o The ICP *can* be stored in flash.
Advantages over current design:
o Lower memory consumption, as we don't track individual nodes anymore.
Advantages over your old ICP concept:
o GC and write are simple. They simply add the current eraseblock to
the ICP list, if it isn't part of it already.
o Whenever we need to check the full node list, we take a few more
o Removal of erase blocks from the ICP list is done on lookup.
"Whoops, this erase block doesn't contain any of my nodes."
Ultimate advantage: Design can be explained in less words. :)
My second remark is that our intellectual powers are rather geared to
master static relations and that our powers to visualize processes
evolving in time are relatively poorly developed.
-- Edsger W. Dijkstra
More information about the linux-mtd