Re: [ECOS] Re: FTP runs out of JFFS2 nodes and trashes the file system

[Andrew Lunn <andrew@lunn.ch>]

>  In this test, after FTP'ing 189 files with in total 3706kB, the file  
> system crashes, but in a "valid" way: indeed, as the counter proofs, the  
> raw node pool is empty, *but how is this possible?*

Jffs2 keeps an in memory copy of the FS meta information. Each write
to the FS results in the creating of a node. Smaller writes results in
more nodes/meta information and so greater RAM usage for the meta
information. Hence you can get into the state of being out of RAM for
meta information but still have space on the filesystem. So i would
suggest writing bigger blocks, use fwrite, not write and use setbuf to
set the buffering to 4K or similar. 

> Therefore my question about FTP in  
> http://ecos.sourceware.org/ml/ecos-discuss/2008-04/msg00110.html.
>  I have to unmount/mount or reboot to be able to delete files again. If  
> I then don't delete but add files instead, it fails with the same error  
> after a few files. When I repeat this cycle of reboot-add files a few  
> times (depending on previous state of the file system) *jffs2  
> "crashes"*: I cannot anymore delete or add any file - listing  
> directories still works, also the application still runs.
> I have to format the flash to solve the problem.

There are a couple of possibilities here. 

umount/mount causes it to rebuild its in RAM meta information which
allows it to remove old nodes which are no longer needed.

It has chance to do a garbage collect of the filesystem so freeing up
some meta information and blocks on the FS.

Note that JFFS2 has unusual behaviour when full. It needs 4 to 5 free
erase blocks in order to do garbage collection. So things like df will
say there is free space, but the filesystem may refuse to write
because garbage collection does not have enough blocks to be able to
run.

>  But I read this in the documentation: "However the library may not be  
> interrupt safe. An interrupt must not cause execution of code that is  
> resident in FLASH." If I understand it well, *this means the library is  
> thread safe on the condition that all code is always executed in RAM?*
> This is ok in my case.

Just watch out for redboot and the virtual vectors. If you are using a
ROM redboot, diag_printf can jump into the ROM redboot. Similar an
exception, or using the debugger could cause the gdb stub in the ROM
redboot to get called. 

        Andrew

-- 
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss