jffs2 copy too long after mounting

[hejianet]

Thanks, Brian
  Here is my latest investigation on the copy_too_long_time issue:
I defined the log level of jffs2 as "noisy",and inserted timestamp for
each jffs2 printk log.
I watched that, there are more lines of such printk compared to good
case.(bad case is first copy, takes 9 minutes, good case is second copy,
takes 1 minute)
1344387878.230899000:<7>Check potential deletion dirent at 0081aad8
1344387878.233899000:<7>Check potential deletion dirent at 00819960
1344387878.236899000:<7>Check potential deletion dirent at 00819388
1344387878.239899000:<7>Check potential deletion dirent at 00818d5c
1344387878.242899000:<7>Check potential deletion dirent at 00818a7c
1344387878.245899000:<7>Check potential deletion dirent at 008141d0
1344387878.248899000:<7>Check potential deletion dirent at 0080e9a0
1344387878.251899000:<7>Check potential deletion dirent at 0080defc
1344387878.254899000:<7>Check potential deletion dirent at 0080dc8c

Thanks for any suggestions or instructions.
kernel version:2.6.16
attached the full logs.

On 2012-08-07 07:02, Brian Norris wrote:
> On Wed, Aug 1, 2012 at 10:58 PM, hejianet <hejianet at linux.vnet.ibm.com> wrote:
>> Is there anyway to show the summary result of jffs2's fragmentation?
>> Is there anyway to manually make defragmentation?
> I'm not a JFFS2 expert, but I don't believe fragmentation really is an
> issue in quite the same way as in spinning-disk, block storage
> filesystems like FAT. Access time to all blocks on an MTD is uniform.
>
> Also, I quite doubt there is a tool that displays the low-level
> details of file/block mapping.
>
> Regards,
> Brian
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>


-------------- next part --------------
A non-text attachment was scrubbed...
Name: copy_too_long.zip
Type: application/octet-stream
Size: 572140 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-mtd/attachments/20120809/286dbd5f/attachment-0001.obj>