public inbox for linux-mtd@lists.infradead.org
 help / color / mirror / Atom feed
From: "Jörn Engel" <joern@wohnheim.fh-wedel.de>
To: "Eric W. Biederman" <ebiederman@lnxi.com>
Cc: linux-mtd@lists.infradead.org
Subject: Re: Q: Filesystem choice..
Date: Sun, 25 Jan 2004 23:49:11 +0100	[thread overview]
Message-ID: <20040125224911.GA12365@wohnheim.fh-wedel.de> (raw)
In-Reply-To: <m3u12jr8y4.fsf@maxwell.lnxi.com>

On Sun, 25 January 2004 14:53:55 -0700, Eric W. Biederman wrote:
> 
> Currently I am examining the possibility of using a filesystem with
> LinuxBIOS so that I may store parameters and kernels in the flash in a
> more flexible manner. 
> 
> The current flash chips I am working with are NOR flash from 512KiB to
> 4MiB.  And they generally have a 64KiB erase size.
> 
> I have two flash blocks that are reserved for XIP code (the hw
> initialization firmware) and the rest can be used for the filesystem.
> So in the worst case I have 6 flash blocks to play with.
> 
> The old papers on jffs2 would make it unacceptable as it reserves
> 5 erase blocks.  And I don't know if yaffs or yaffs2 is any better.
> 
> 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.
> 
> Is there a filesystem that only reserves one erase block?
> 
> Does it look like I need to write my own solution?

Not necessarily.  Disable compression for jffs2 and you should be able
to get away with two reserved blocks, or even 80kiB or so.  But that
requires changes to current code and lots of testing.  Compression
makes things more complicated, basically impossible to calculate, so
you have to reserve a little more and hope for the best.  Five blocks
are *very* conservative for a filesystem of six block total, though.

The idea is pretty old, it's just that noone cared enough to do all
the work.

Jörn

-- 
Fancy algorithms are buggier than simple ones, and they're much harder
to implement. Use simple algorithms as well as simple data structures.
-- Rob Pike

  reply	other threads:[~2004-01-25 22:49 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 [this message]
2004-01-26  6:42 ` David Woodhouse
2004-01-26  7:09   ` Eric W. Biederman
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=20040125224911.GA12365@wohnheim.fh-wedel.de \
    --to=joern@wohnheim.fh-wedel.de \
    --cc=ebiederman@lnxi.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