public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: Thomas Gleixner <tglx@linutronix.de>
To: Andy Hawkins <a.hawkins@cabletime.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Large JFFS2 filesystem problem
Date: Tue, 27 Jul 2004 14:11:38 +0200	[thread overview]
Message-ID: <1090930297.20889.93.camel@thomas.tec.linutronix.de> (raw)
In-Reply-To: <1090923928.2237.6.camel@adh>

On Tue, 2004-07-27 at 12:25, Andy Hawkins wrote:

>  * Check, if we have to concatenate physical blocks to larger virtual
> blocks
>  * to reduce the memorysize for c->blocks. (kmalloc allows max. 128K
> allocation)
>  */
> c->sector_size = c->mtd->erasesize; 
> blocks = c->flash_size / c->sector_size;
> while ((blocks * sizeof (struct jffs2_eraseblock)) > (128 * 1024)) {
> 	blocks >>= 1;
> 	c->sector_size <<= 1;
> }	
> 
> could be the source of the proble, because while it decreases the number
> of blocks, it increases the sector size, and it is this sector size that
> is used in the kmalloc line that fails.

Sure, the combination of sector size and number of sectors in relation
to the maximum allocation size of 128K is the limitation.

It should be easy to fix the scan code. All we have to do is to reduce
the chunk size which we read in one go. The functionality to do so is
already there and its simple to make it work

Can you try the following patch ?
Please let me know if it works.

Index: scan.c
===================================================================
RCS file: /home/cvs/mtd/fs/jffs2/scan.c,v
retrieving revision 1.110
diff -u -r1.110 scan.c
--- scan.c      17 Jun 2004 17:15:31 -0000      1.110
+++ scan.c      27 Jul 2004 12:15:52 -0000
@@ -104,6 +104,10 @@
                else
                        buf_size = PAGE_SIZE;
  
+               /* Respect kmalloc limitations */
+               if (buf_size > 128*1024)
+                       buf_size = 128*1024;
+
                D1(printk(KERN_DEBUG "Allocating readbuf of %d bytes\n",
buf_size));
                flashbuf = kmalloc(buf_size, GFP_KERNEL);
                if (!flashbuf)

> Previously, someone recommended waiting for YAFFS2, as this is likely to
> be more efficient with large filesystems. Does anyone have any idea as
> to when this is likely to be available?

Ask on the YAFFS mailing list.

tglx

  reply	other threads:[~2004-07-27 12:17 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-27 10:25 Large JFFS2 filesystem problem Andy Hawkins
2004-07-27 12:11 ` Thomas Gleixner [this message]
2004-07-27 13:44   ` Andy Hawkins
2004-07-27 14:10     ` Thomas Gleixner
2004-07-28 14:17   ` Andy Hawkins

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=1090930297.20889.93.camel@thomas.tec.linutronix.de \
    --to=tglx@linutronix.de \
    --cc=a.hawkins@cabletime.com \
    --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