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
next prev parent 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