Delay in mounting on jffs2 file system.

["Nilesh Tayade" <ntayade@nortel.com>]

Hi,

I am facing an issue related to jffs2 file system used for a flash
device on one of our systems. I am not too familiar with jffs2 file
system functionality. I tried reaching to the jffs mailing list (jffs-
dev@axis.com) but the email bounces back. Appreciate if I can get any
pointers here. Please keep me in copy while replying as I am not added
to the mailing list.

Details:
As a part of one of the audit daemons, we unmount and remount the mount
point on jffs2 file system once in 24hrs.
Commands:
# umount /mnt/cfpart2
# /bin/mount -t jffs2 -o noatime,ro /dev/mtdblock10 /mnt/cfpart2

However, the mount command takes a bit longer (~600ms-700ms) - it hogs
the CPU during the operation and hence other sensitive 
daemons running on that CPU report this as delay (which is not
tolerable). I do not have the option to change the tolerable 
delay threshold for the sensitive daemon.

Kernel version : vanilla 2.6.14 kernel (heavily patched for ATCA
specific usage, but jffs2 part has no modifications).

* Has anyone observed/cared to observe such behavior with jffs2 file
system?
* Also I tried adding below code in wbuf.c and it seems working fine
without any delay reported.

--- linux.orig/fs/jffs2/wbuf.c       2010-05-20 02:52:27.935790000 -0400
+++ linux/fs/jffs2/wbuf.c       2010-05-20 06:28:24.280242000 -0400
@@ -923,6 +923,9 @@ int jffs2_flash_read(struct jffs2_sb_inf

 exit:
        up_read(&c->wbuf_sem);
+#ifdef CONFIG_XXXX             // board specific config parameter.
+       cond_resched();
+#else
        return ret;
 }

We don't seem to be called through interrupt handler here. Also the code
walkthrough shows we do not hold any spinlock etc. while calling this
function directly/indirectly. 

* I would like to know will it be safe to call cond_resched() here? I
see cond_resched() calls in some other functions in jffs2.


Thanks in advance.

-- 
Thanks,
Nilesh T.
[ntayade(at)nortel(dot)com]