From: "Rudi Engelbertink" <rudi@unsec.nl>
To: tglx@linutronix.de
Cc: linux-mtd@lists.infradead.org
Subject: Re: jffs2_get_inode_nodes() very very slow
Date: Wed, 2 Feb 2005 13:26:00 +0100 [thread overview]
Message-ID: <20050202112025.M50509@unsec.nl> (raw)
In-Reply-To: <1107340012.21196.507.camel@tglx.tec.linutronix.de>
On Wed, 02 Feb 2005 11:26:51 +0100, Thomas Gleixner wrote
> On Wed, 2005-02-02 at 10:05 +0100, Rudi Engelbertink wrote:
> > The powerfail tests are done by:
> > A. a clock. Just turn off and on the power every 15 minutes and start the
> > an application which logs 2 40-60 byte events every second.
> > ...
> > Yes, the root is accessable but the directory where the logging is stored,
> > is unavailable for several minutes.
>
> You hit the worst case for JFFS2.
>
> Your event logging creates tons of small nodes for your logfiles.
> Actually are about 96000 very small nodes on the chip, so the mount time
> is not surprising. This also will use a quite big amount of memory.
>
> We have no real cure for this at the moment. We have this scenario in
> our design list for JFFS3. I remember that somebody else came up with
> this issue sometime ago. IIRC changing the log method did help a bit.
>
> while true
> do
> log_event
> let cnt=cnt+1
> if [ $cnt -ge $LIMIT ]
> then
> closelog
> cat log.small >>log.big
> rm log.small
> fi
> done
>
> This converts the small nodes to bigger nodes when the data are appended
> to log.big. I guess garbage collection should kick in quite fast and
> clean up the small nodes. It might not totally go away, but it
> should be much better than now. This will also give you more
> capacity on your partition as the small nodes consist mostly of node
> overhead.
Digging through the logfile I noticed that several inodes had a lot of
versions. Especialy the inode #737 which had 60000+ versions.
This is a bit strange because this is a 16 byte pointer file which will
be opened once and never closed. This should not result in 60000+ versions.
A copy move action (cp -p file file.cp && mv file.cp file) indeed makes a big
performance improvement.
Will a regular close open of this file make some improvement regarding the
stored version information of this inode. During normal operations this file,
and some other files, never gets closed. So there will be never a 'commit'.
So after a powerfail, all the inode version information must be checked.
>
> You may also try YAFFS for the logging partition. It should deal with
> this situation a bit better.
>
> tglx
RGDS Rudi.
--
They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.
Benjamin Franklin (1706-1790), Letter to Josiah Quincy, Sept. 11, 1773.
GnuPG Key fingerprint = 706C E2AC 7AE2 BCEE 04EB A962 0A75 7F9B 07A1 83E8
next prev parent reply other threads:[~2005-02-02 12:26 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-02-01 15:32 jffs2_get_inode_nodes() very very slow Rudi Engelbertink
2005-02-01 16:03 ` Artem B. Bityuckiy
2005-02-02 9:05 ` Rudi Engelbertink
2005-02-02 10:26 ` Thomas Gleixner
2005-02-02 10:35 ` David Woodhouse
2005-02-02 11:23 ` Artem B. Bityuckiy
2005-02-02 12:26 ` Rudi Engelbertink [this message]
2005-02-02 12:41 ` Thomas Gleixner
2005-02-01 16:10 ` Thomas Gleixner
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=20050202112025.M50509@unsec.nl \
--to=rudi@unsec.nl \
--cc=linux-mtd@lists.infradead.org \
--cc=tglx@linutronix.de \
/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