Hi Pawel, On Thursday 20 February 2014 23:49:23 Pawel Suchanecki wrote: > My Mini2440 boards running Linux 3.7.1-ptx-2012.12.0 on JFFS2 based > root filesystems take very long to boot (as shown below), so I am > looking for a way of solving this issue. > > There is a possibility that boards with "long boot time problem" are > not halted properly (powered off before the system halts), although > they do not report more bad blocks than the others. Can this be the > root cause of the problem? > > What else can cause this behaviour? > > I know that mount time for JFFS2 increases with number of files > stored, but in my case the number of files is pretty much the same in > both cases.
I'm not sure the time to mount a JFFS2 increases with the file count. As JFFS2 must follow a linked list it must scan the whole flash prior mounting to find the tail of this list. AFAIR the mount time increases with the size of the NAND. > Does this happen due to JFFS2 index generation & garbage collection > processes? After writing the JFFS2 image to the NAND partition some kind of resize process is running while the first time mount (to increase the JFFS2 filesystem to the full size of the partition). > If so, shouldn't the boot time reduce on next boot once garbage > collector finishes its work and there are no new writes? (actually > there are new to /etc/mtab for instance) What I have seen is: after the first time mount you should spend some time to wait until the resize (or something else) is done. With the tool 'top' you can see and monitor the JFFS2 background process. > I assume that switching rootfs to UBIFS will help to aid this issue, > am I correct? Maybe ;) > Long boot time case: > > [ 18.430000] devtmpfs: mounted > [ 18.435000] Freeing init memory: 120K > > >[ 79.140000] udevd[487]: starting version 182 Hmm, I have never seen such a long delay. Can you enable all MTD related debug features in the kernel and run this kernel on this specific target again? (run it with kernel commandline parameter 'debug') Maybe the NAND is somehow broken. I don't know where to look, but there should be something like an ECC error counter. If this counter reports many errors (correctable or not) you should not use this NAND anymore. It's worn out in this case. Regards, Juergen -- Pengutronix e.K. | Juergen Beisert | Linux Solutions for Science and Industry | http://www.pengutronix.de/ |
