All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederman@lnxi.com (Eric W. Biederman)
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Q: Filesystem choice..
Date: 26 Jan 2004 00:09:34 -0700	[thread overview]
Message-ID: <m3bror89u9.fsf@maxwell.lnxi.com> (raw)
In-Reply-To: <1075099329.17157.97.camel@lapdancer.baythorne.internal>

David Woodhouse <dwmw2@infradead.org> writes:

> On Sun, 2004-01-25 at 14:53 -0700, Eric W. Biederman wrote:
> > The old papers on jffs2 would make it unacceptable as it reserves
> > 5 erase blocks. 
> 
> It's got slightly different heuristics now -- a proportion of total
> size, plus a proportion of total _blocks_. That was done primarily to
> deal with NAND flash, where we need _more_ blocks reserved, but it
> should also have helped with small NOR flashes. 
> 
> You blatantly don't _need_ to reserve five erase blocks to let you
> rewrite the contents of the remaining, erm, one erase block full of
> data. You can tune this; it's not a mount option but it's relatively
> simple to change in the code.

Has anyone gotten as far as a proof.  Or are there some informal
things that almost make up a proof, so I could get a feel?  Reserving
more than a single erase block is going to be hard to swallow for such
a small filesystem. 

> >  And I don't know if yaffs or yaffs2 is any better.
> 
> They're for NAND, not NOR flash.

I think I have heard about a port to NOR flash, but tuned
for NAND flash I would be really surprised if they were different.
 
> > In addition boot time is important so it would be ideal if I did not
> > to read every byte of the ROM chip to initialize the filesystem.
> 
> There have been efforts to improve JFFS2 performance in this respect. It
> still reads the _header_ from each node of the file system, but doesn't
> actually checksum every node any more.

That should help.  It bears trying to see how fast things are.

Eric

  reply	other threads:[~2004-01-26  7:07 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-01-25 21:53 Q: Filesystem choice Eric W. Biederman
2004-01-25 22:49 ` Jörn Engel
2004-01-26  6:42 ` David Woodhouse
2004-01-26  7:09   ` Eric W. Biederman [this message]
2004-01-26  7:40     ` David Woodhouse
2004-01-26  8:34       ` Joakim Tjernlund
2004-01-26  8:38         ` David Woodhouse
2004-01-26  9:28           ` Joakim Tjernlund
2004-01-26  9:23       ` Eric W. Biederman
2004-01-26  9:31         ` David Woodhouse
2004-01-26 16:20           ` Eric W. Biederman
2004-01-26 15:32       ` Jörn Engel
2004-01-27  4:30 ` Charles Manning
2004-01-27  7:13   ` Eric W. Biederman

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=m3bror89u9.fsf@maxwell.lnxi.com \
    --to=ebiederman@lnxi.com \
    --cc=dwmw2@infradead.org \
    --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.