Q: jffs2 startup slow-down / cleanup

[Albrecht Dreß]

Hi all,

I use a PPC-based system, running kernel 3.2.41, including a 512 kByte NV RAM chip which is integrated as mtd-ram with a JFFS2 file system with lzo compression.  In fs/jffs2/background.c, I found the note

	/* Problem - immediately after bootup, the GCD spends a lot
	 * of time in places like jffs2_kill_fragtree(); so much so
	 * that userspace processes (like gdm and X) are starved
	 * despite plenty of cond_resched()s and renicing.  Yield()
	 * doesn't help, either (presumably because userspace and GCD
	 * are generally competing for a higher latency resource -
	 * disk).

The first task I launch activates the hardware watchdog of the system, and accesses data on the NV RAM.  When the NV RAM is newly initialised, everything works fine, i.e. a high load after booting is visible only for a very short period (<< 1 second).

I then create, modify and erase files on that file system, and apparently the time needed increases with each boot (I observed about 3-4 seconds) - up to a point where the user space process is too slow the trigger the wdt properly.  Thus, the system is rebooted by the wdt, which again checks the JFFS2 in background, and the wdt triggers...  The only remedy in this situation is to erase the NV RAM by removing the buffer battery.

I could add a delay between mounting the NV RAM and starting my main application, but of course this is not desirable, as the system should come up as quick as possible.  The alternative would be waiting until the background task has finished, or to regularly "clean up" the jffs2.

My questions:

- Is it possible to detect (e.g. through sysfs) when the background task has finished, so it's safe to activate the WDT (i.e. optimise the delay between mount and wdt activation)?

- Is it possible to clean/re-organise the jffs2 so the background process needs less time (optimal: a constant time) after booting?

Thanks in advance,
Albrecht.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 190 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20130424/53a31d0e/attachment.sig>