public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: David Woodhouse <dwmw2@infradead.org>
To: Martin Egholm Nielsen <martin@egholm-nielsen.dk>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 garbage collector blocking for minutes after mount
Date: Wed, 20 Jul 2005 09:45:30 -0400	[thread overview]
Message-ID: <1121867130.12903.15.camel@localhost.localdomain> (raw)
In-Reply-To: <dbl42b$hcn$1@sea.gmane.org>

On Wed, 2005-07-20 at 11:03 +0200, Martin Egholm Nielsen wrote:
> 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. 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.

-- 
dwmw2

  reply	other threads:[~2005-07-20 13:45 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 [this message]
2005-07-20 14:12   ` Martin Egholm Nielsen
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=1121867130.12903.15.camel@localhost.localdomain \
    --to=dwmw2@infradead.org \
    --cc=linux-mtd@lists.infradead.org \
    --cc=martin@egholm-nielsen.dk \
    /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