[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Re: Node cache too large
Martin Gadbois <firstname.lastname@example.org> writes:
> cat /proc/slabinfo
> while :; do
> echo "12345678901234567890123456789012345678901234567890" >>
> break after a while, check /proc/slabinfo before and after... and
> On my small embedded environment, slab-32 and slab-64 (struct
> make up for around 1.7M of RAM!
> - Combine small entries into one large node (?) at scan or GC
Your example hits the Achille's heel of JFFS. Each write
creates a jffs_node both in RAM and in flash. By the authors'
own admission garbage collection needs work.
This is a good reason not to use JFFS for frequent logging.
It is clearly inefficient use of flash and RAM. JFFS is great
for Read-Only mounts and for Read-Write situations requiring
the very occasional write (i.e. upgrading applications
or config files, etc.).
Before JFFS can hit the "big-time" it needs work in this area.
It is still relatively new and I am sure they are accepting
I think one of the things on their list of things to do is
being able to take a "bad erase unit" out of service.
This will require JFFS to become more "erase unit" aware.
Which in-turn will make garbage collection easier, the file
system does not have to be a contiguous chunk moving through
flash. Garbage collection could de-frag these high node count
files, then look for erase-units that can be freed with
little or no node relocation. So as you noted, the only
real way to solve this problem:
1) Make JFFS more erase-unit aware.
2) De-frag the files.
3) Locate erase-units with high percentage of "freed" nodes.
4) Relocate "in-use" nodes.
5) Free the erase-unit and eliminate the nodes for the
Just some idle thoughts.
The Late Night Software Shop
Sign up today for your Free E-mail at: http://www.canoe.ca/CanoeMail
To unsubscribe from this list: send the line "unsubscribe jffs-dev" in
the body of a message to email@example.com