From: Martin Egholm Nielsen <martin@egholm-nielsen.dk>
To: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 garbage collector blocking for minutes after mount
Date: Wed, 20 Jul 2005 16:12:37 +0200 [thread overview]
Message-ID: <dblm4l$802$1@sea.gmane.org> (raw)
In-Reply-To: <1121867130.12903.15.camel@localhost.localdomain>
>>I have a "small" NAND device (32MByte) with JFFS2 on top used as the
>>root-fs on my system. It's been working like a charm - until just now.
>>After (over)writing a relative large file (11 megs uncomp. -
>>~3-5compr.), the garbage collector (jffs2_gcd_mtd0) uses 8:45 minutes of
>>CPU time (~99%) after booting - blocking any write operations.
>>Ok, I accept that some GC'ing should be performed when going "beyond the
>>edge" - but shouldn't this be a one-time process, so the next time I
>>boot this is done with?
>>I see it everytime I reboot - without touching any files on the system...
>>I use the mtd source from 2005-03-04...
> The garbage collection thread is also responsible for building up the
> node tree for every inode after mounting, so that we know for sure which
> nodes are valid and which are obsolete.
So you think this is what consumes the time?
> On NAND flash we can't actually mark nodes as obsolete.
> We've made some significant improvements to that process since March,
> especially where inodes with large numbers of nodes are concerned. We
> used to sort all the nodes into a linked list before building the tree,
> but now we use a tree data structure for that instead -- so it's
> O(n log n) instead of O(n²) in the number of nodes.
> Artem has patches which should improve it still further -- I'm not sure
> if they are committed yet.
Sounds interesting... Artems states it'll be ready sometimes soon (a
week or so from now...)
BR,
Martin
next prev parent reply other threads:[~2005-07-20 14:13 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-07-20 9:03 JFFS2 garbage collector blocking for minutes after mount Martin Egholm Nielsen
2005-07-20 13:45 ` David Woodhouse
2005-07-20 14:12 ` Martin Egholm Nielsen [this message]
2005-07-20 14:19 ` David Woodhouse
2005-07-20 14:34 ` Martin Egholm Nielsen
2005-07-20 19:17 ` David Woodhouse
2005-07-21 9:23 ` Stephane Fillod
2005-07-22 14:47 ` Martin Egholm Nielsen
2005-07-23 15:07 ` David Woodhouse
2005-07-24 20:09 ` Martin Egholm Nielsen
2005-07-25 9:49 ` Artem B. Bityuckiy
2005-07-25 9:58 ` Martin Egholm Nielsen
2005-07-27 7:10 ` Martin Egholm Nielsen
2005-07-26 13:04 ` Ferenc Havasi
2005-07-26 13:06 ` Artem B. Bityuckiy
2005-07-26 13:16 ` Ferenc Havasi
2005-07-26 13:08 ` Martin Egholm Nielsen
2005-07-26 13:14 ` Steven Scholz
2005-07-26 14:05 ` Ferenc Havasi
2005-07-26 14:06 ` Steven Scholz
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='dblm4l$802$1@sea.gmane.org' \
--to=martin@egholm-nielsen.dk \
--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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.