From: Amit D Chaudhary <amit@muppetlabs.com>
To: David Woodhouse <dwmw2@infradead.org>
Cc: linux-kernel@vger.kernel.org
Subject: RAMFS, CRAMFS and JFFS2(was Re: /linuxrc query)
Date: Fri, 23 Mar 2001 10:00:55 -0800 [thread overview]
Message-ID: <3ABB8F57.3000800@muppetlabs.com> (raw)
In-Reply-To: <3ABAF64A.1040106@muppetlabs.com> <3ABAEED2.6020708@muppetlabs.com> <20010323075107.Q3932@almesberger.net> <9118.985356471@redhat.com>
Hi David,
I did consider CRAMFS and JFFS2 when it was announced on the mtd list.
Conserving flash over system ram is more relevant. Our reasons are below:
RAMFS v/s CRAMFS
1. RAMFS is just more stable in terms of less complexity, less bugs reported
over the time, etc.
2. RAMFS is a fairly robust filesystem and all features required as far as I can
tell.
RAMFS v/s ext2 on a ramdisk
1. Fixed size. Results in overallocation or more dangerously overshooting the
size decided earlier during mke2fs.
RAMFS v/s JFFS2
1. JFFS2 was announced around a month ago and few utils were still in
development, hence it was not there for the first development cycle.
2. Just offhand, joining 100 small files (say in /etc) and then compressing into
a one file over these 100 files in a JFFS2 fs seems to give better overall space
usage and probably less flash wear during modifications.
3. JFFS2 does has some compelling reasons, more robustness ofcourse with JFFS2
over above approach, flash wearing(though would require sufficient free space on
that mtd partition), etc. Plan to compare these later.
I might be wrong and hence would welcome any suggestions.
Regards
Amit
David Woodhouse wrote:
> amit@muppetlabs.com said:
>
>> Also as a note, what we are doing is keeping our rootfs on flash as a
>> tar.gz and reading it and mounting it on a ramfs in the /linuxrc
>> before doing a pivot_root. To summarize, pivot_root has been a life
>> saver as the earlier real_root_dev might not have been useful in this
>> case. Not using the ramfs limits for now, will do soon.
>
>
> If you're concerned about memory usage - why untar the whole of your root
> filesystem into a ramfs? My preferred solution is to just mount the root
> filesystem directly from the flash as cramfs (or JFFS2), with symlinks into a
> ramfs for appropriate parts like /tmp and /var.
>
> I suppose the best option is actually to union-mount the ramfs over the
> root, rather than mucking about with symlinks. I just haven't got round to
> doing that yet.
>
> --
> dwmw2
next prev parent reply other threads:[~2001-03-23 18:03 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-03-23 6:36 /linuxrc query Amit D Chaudhary
2001-03-23 6:51 ` Werner Almesberger
2001-03-23 7:00 ` Amit D Chaudhary
2001-03-23 11:18 ` Werner Almesberger
2001-03-23 17:46 ` Amit D Chaudhary
2001-03-23 7:07 ` Amit D Chaudhary
2001-03-23 11:24 ` Werner Almesberger
2001-03-23 14:07 ` David Woodhouse
2001-03-23 18:00 ` Amit D Chaudhary [this message]
2001-03-23 19:37 ` RAMFS, CRAMFS and JFFS2(was Re: /linuxrc query) David Woodhouse
2001-03-23 20:25 ` CRAMFS Bjorn Wesen
2001-03-23 22:01 ` CRAMFS Amit D Chaudhary
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=3ABB8F57.3000800@muppetlabs.com \
--to=amit@muppetlabs.com \
--cc=dwmw2@infradead.org \
--cc=linux-kernel@vger.kernel.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