Re: JFFS2 Garbage collection issue

["Albrecht Dreß" <albrecht.dress@arcor.de>]

[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]

Hi Harald:

I had *exactly* the same issue with a board based on a MPC5200 (PPC).  I use kernel 3.2, and the problematic file system is a jffs2 on a NVRAM which is used to hold quickly changing logs and event buffers (before they are shifted to flash or a CF card).  Apparently the scan process is triggered immediately when the NVRAM is mounted by the startup script.  Apart from that I had the same picture - the scan eats so much time that the hw wdt is triggered... (see my original post <http://lists.infradead.org/pipermail/linux-mtd/2013-April/046632.html> - I unfortunately never got an answer to it).

My solution was to add a task to the startup script which monitors the scan process (jffs2_gcd_mtd6 in my case) and waits until it apparently finished.  The main application (which in turn activates the hardware wdt) is launched only *afterwards*; then everything seems to run just fine, even if there is much "traffic" on the nvram.

The monitor application basically identifies the pid of the jffs2_gcd_mtd6, and then repeatedly reads /proc/<pid>/stat as long as the sum of the utime, stime, cutime and cstime is still growing (of course with a maximum loop count, so the system doesn't deadlock).

Hope this helps,
Albrecht.


Am 27.11.13 11:11 schrieb(en) Albrecht, Harald:
> Hi all,
> 
> we are currently facing a problem with the Garbage-collection on a JFFS2 file system.
> 
> We have an embedded linux system based on an ARM9 AT91RM9200 processor with an Intel / Micron JS28F256 NOR-flash of 32MB in size.
> The Flash holds the U-Boot loader and its environment and in the main part (30MB) of the chip a JFFS2-based root-file-system.
> Our Linux kernel version is 2.6.24.3
> 
> Some minutes after startup of the system, the garbage collector (gc.c) does a scan of the file system, gathering information for the garbage collection procedures that may be initiated based upon that data.
> On some file systems, especially such with long runtime and therefore many file operations, this scan consumes a lot of time. On some systems it stays in that scan for more that 10 minutes. The problem with this behaviour is the fact, that during the scan the file system is locked, and therefore all file operations are suspended. This leads to a crash of the system, when the application program hangs for a long time, waiting for a file operation to return from a system call, and the watchdog is not triggered.
> 
> In a test system without watchdog, after the scan, the system runs normally.
> The flash chip itself shows no errors, so it seems to be a problem of the file system.
> 
> Any idea or suggestion to solve the problem would be very welcome!
> 
> Harald Albrecht
> 
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
> 

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]