All of lore.kernel.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 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.