From: hejianet <hejianet@linux.vnet.ibm.com>
To: linux-mtd@lists.infradead.org
Subject: Re: jffs2 copy too long after mounting
Date: Thu, 09 Aug 2012 13:31:00 +0800 [thread overview]
Message-ID: <50234B14.5010000@linux.vnet.ibm.com> (raw)
In-Reply-To: <CAN8TOE8+A+kG8A9sB_qiD9huCWR-bwSiEkgjEqSXohFGdsEGkg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1774 bytes --]
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@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/
>
>
[-- Attachment #2: copy_too_long.zip --]
[-- Type: application/octet-stream, Size: 572140 bytes --]
next prev parent reply other threads:[~2012-08-09 5:31 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-08-02 3:04 jffs2 copy too long after mounting hejianet
2012-08-02 3:16 ` hejianet
2012-08-06 22:54 ` Brian Norris
2012-08-02 5:58 ` hejianet
2012-08-06 23:02 ` Brian Norris
2012-08-09 5:31 ` hejianet [this message]
2012-08-24 7:53 ` Artem Bityutskiy
2012-10-23 7:13 ` hejianet
2012-11-12 15:35 ` Artem Bityutskiy
[not found] <50881109.3010107@linux.vnet.ibm.com>
2012-10-25 1:41 ` hejianet
2012-10-26 1:45 ` hejianet
2012-11-12 15:42 ` Artem Bityutskiy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=50234B14.5010000@linux.vnet.ibm.com \
--to=hejianet@linux.vnet.ibm.com \
--cc=linux-mtd@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).