public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Pantelis Antoniou <panto@intracom.gr>
To: David Ho <DavidHo@nanometrics.ca>
Cc: linux-mtd@lists.infradead.org
Subject: Re: JFFS2 behaviour when large number of files are created.
Date: Tue, 19 Oct 2004 16:22:25 +0300	[thread overview]
Message-ID: <41751511.2060607@intracom.gr> (raw)
In-Reply-To: <OF9C244FBD.F36AE939-ON85256F31.00585A10-85256F31.005A79E1@nanometrics.ca>

David Ho wrote:

>
>
>Hi all,
>
>I have a snapshot of the CVS MTD/JFFS2 code from Sept 22 patched into a
>2.4.24 kernel.  In the process of running a varied set of applications on
>the system, a program was creating a large number of small files each less
>than 1KB.  The Linux card is powered up for a short period of time to dump
>data to persistent storage, then it is powered down for until the next data
>dump.  As the sytem is run, the mount is becoming slower to a point that
>the watchdog is reset the card.
>
>It appears that JFFS2 is bad for certain usage patterns.  Creating large
>number of files is one.  What other usage patterns should I avoid?
>
>Creating a large file?
>Removing and updating a large file?
>
>Also , the kernel is crashing at one instance in gc.c.  Is this a known
>problem in 2.4?
>
>Checked all inodes but still 0x406868 bytes of unchecked space?
>kernel BUG at gc.c:139!
>Oops: Kernel Mode Software FPU Emulation, sig: 8
>NIP: C009DBF4 XER: 00000000 LR: C009DBF4 SP: C7DADEF0 REGS: c7dade40 TRAP:
>1000
>   Not tainted
>MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
>TASK = c7dac000[8] 'jffs2_gcd_mtd2' Last syscall: -1
>last math 00000000 last altivec 00000000
>GPR00: C009DBF4 C7DADEF0 C7DAC000 00000018 00001032 00000001 00000000
>C01C0000
>GPR08: 000010F4 C0191590 00000000 C7DADE10 42008024 1001E76C 07FFC000
>007FFF16
>GPR16: 00000000 00000001 007FFF00 07FFABA0 00000000 FFFFFFFF 07FBADE8
>00000002
>GPR24: 00000000 C7FA5918 00000000 C7FA5928 C7DADFB8 C7DB32C0 C7FA58F4
>C7FA5928
>Call backtrace:
>C009DBF4 C00A0E20 C0006D00
>
>Regards,
>David Ho
>
>
>______________________________________________________
>Linux MTD discussion mailing list
>http://lists.infradead.org/mailman/listinfo/linux-mtd/
>
>
>  
>
I can confirm the same behaviour on 2.4.28 + latest snapshot.

Now what?

Any ideas for a workaround?

Regards

Pantelis

  reply	other threads:[~2004-10-19 13:27 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-18 16:28 JFFS2 behaviour when large number of files are created David Ho
2004-10-19 13:22 ` Pantelis Antoniou [this message]
2004-10-19 18:16 ` Jan Vestby
2004-10-19 18:42   ` David Woodhouse
2004-10-20  9:23     ` Artem B. Bityuckiy

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=41751511.2060607@intracom.gr \
    --to=panto@intracom.gr \
    --cc=DavidHo@nanometrics.ca \
    --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