From: Matthieu CASTET <matthieu.castet@parrot.com>
To: linux-mtd@lists.infradead.org, David Woodhouse <dwmw2@infradead.org>
Subject: Jffs2 and big file = very slow jffs2_garbage_collect_pass
Date: Thu, 17 Jan 2008 17:12:29 +0100 [thread overview]
Message-ID: <478F7E6D.8010300@parrot.com> (raw)
Hi,
we have a 240 MB jffs2 partition with summary enabled and no
compression. We use 2ad8ee713566671875216ebcec64f2eda47bd19d git jffs2
version
(http://git.infradead.org/?p=mtd-2.6.git;a=commit;h=2ad8ee713566671875216ebcec64f2eda47bd19d)
On this partition we have several file (less than 1 MB) and a big file
in the root (200 MB).
The big file is a FAT image that is exported with usb-storage (with usb
device) or mounted on a loopback device.
After some FAT operations, we manage to get in a situation were the
jffs2_garbage_collect_pass take 12 minutes.
jffs2_lookup for the big file (triggered with a ls in the root) take 12
minutes.
If we do a ls without waiting that jffs2_garbage_collect_pass finish, ls
takes 12 minutes to complete.
We applied the 4 patches starting from "Trigger garbage collection when
very_dirty_list size becomes excessive" to "Don't count all 'very dirty'
blocks except in debug mode", but it doesn't change anything.
Why jffs2 take so much time in jffs2_garbage_collect_pass for checking
the nodes ?
Reading the whole raw flash take about 40s-1min.
Does it read the flash in a random order ?
What does the jffs2_lookup ?
Why it is so long.
What are the alternative ?
Trying yaffs2 ?
Export a smaller file ?
Matthieu
PS : if the big file is moved in a subdirectory, then the ls in the root
dir is fast, but access to the big file is slow (12 Minutes).
next reply other threads:[~2008-01-17 16:13 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-01-17 16:12 Matthieu CASTET [this message]
2008-01-17 16:26 ` Jffs2 and big file = very slow jffs2_garbage_collect_pass Jörn Engel
2008-01-17 17:43 ` Josh Boyer
2008-01-18 9:39 ` Matthieu CASTET
2008-01-18 12:48 ` Josh Boyer
2008-01-18 16:17 ` Matthieu CASTET
2008-01-18 17:55 ` Josh Boyer
2008-01-18 18:17 ` Jörn Engel
2008-01-21 15:57 ` Matthieu CASTET
2008-01-21 21:25 ` Jörn Engel
2008-01-21 22:16 ` Josh Boyer
2008-01-21 22:29 ` Jörn Engel
2008-01-22 8:57 ` Matthieu CASTET
2008-01-22 12:03 ` Jörn Engel
2008-01-22 13:24 ` Ricard Wanderlof
2008-01-22 15:05 ` Jörn Engel
2008-01-23 9:23 ` Ricard Wanderlof
2008-01-23 10:19 ` Jörn Engel
2008-01-23 10:41 ` Ricard Wanderlof
2008-01-23 10:57 ` Jörn Engel
2008-01-23 11:57 ` Ricard Wanderlof
2008-01-23 13:01 ` Jörn Engel
2008-01-23 13:16 ` Ricard Wanderlof
2008-01-23 14:06 ` Jörn Engel
2008-01-23 14:25 ` Ricard Wanderlof
2008-01-21 22:36 ` Glenn Henshaw
2008-01-18 17:20 ` Glenn Henshaw
2008-01-18 18:39 ` Jamie Lokier
2008-01-18 21:00 ` Jörn Engel
2008-01-19 0:23 ` Jamie Lokier
2008-01-19 2:38 ` Jörn Engel
2008-01-17 23:22 ` David Woodhouse
2008-01-18 9:45 ` Matthieu CASTET
2008-01-18 18:20 ` Jamie Lokier
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=478F7E6D.8010300@parrot.com \
--to=matthieu.castet@parrot.com \
--cc=dwmw2@infradead.org \
--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