cramfs

cramfs

[Trever L. Adams]

I hate to ask this, however here goes.  I am doing some remote upgrading 
and some other really funky stuff to some boxes I keep up.

Part of these are total system upgrades and I need to move data out of 
the way while still having a working box.  I decided that cramfs may be 
the way to do this.  If you can tell me no and point me to a resource on 
how to do this, I would LOVE to hear about it.

However, the question is, how can I tell lilo to tell the kernel too 
boot off a cramfs file system?  I have already created the file with 
/etc /bin /sbin /dev and /lib from a working system, doing the correct 
deletions and other such changes.  I have a 15 meg cramfs that should do 
the trick.

Thank you for any help you can offer.

Trever Adams

Re: cramfs

[Daniel Quinlan]

"Trever L. Adams" <vichu@digitalme.com> writes:

> I hate to ask this, however here goes.  I am doing some remote upgrading 
> and some other really funky stuff to some boxes I keep up.
> 
> Part of these are total system upgrades and I need to move data out of 
> the way while still having a working box.  I decided that cramfs may be 
> the way to do this.  If you can tell me no and point me to a resource on 
> how to do this, I would LOVE to hear about it.
> 
> However, the question is, how can I tell lilo to tell the kernel too 
> boot off a cramfs file system?  I have already created the file with 
> /etc /bin /sbin /dev and /lib from a working system, doing the correct 
> deletions and other such changes.  I have a 15 meg cramfs that should do 
> the trick.
> 
> Thank you for any help you can offer.

You want "cramfsboot" to boot cramfs root partitions directly.
(You'll also need the cramfs patch which is part of the Midori Linux
kernel package.)

ftp://midori.transmeta.com/midori-1.0.0-beta2/apps/cramfsboot-0.2_ML1.0.0-beta2-5.mlz

(It's a tarball.)

There are also several packages that handle upgrades of cramfs
partitions, etc.

- Dan

CRAMFS

[Bradley Bozarth]

Daniel Quinlan originally maintained this, now it is orphaned.  His endian
patch, which implemented the correct behavior according to the docs (which
basically listed always do little endian as a todo), was dropped.

We have been maintaining this patch on our kernel, but it really should go
in - I don't want to spend a ton of time like I did last time to have it
dropped again, however - is anyone thinking of maintaining cramfs?  What
are the chances of the endian fix going in if I submit it again?  (if even
the former maintainer had no success).  I would maintain cramfs if desired
- it hasn't really changed in a long time except in regards to higher
level fs changes.

Thanks,
Brad

Re: CRAMFS

[H. Peter Anvin]

Followup to:  <35438.128.107.165.13.1068235628.squirrel@mail.yumbrad.com>
By author:    "Bradley Bozarth" <prettygood@cs.stanford.edu>
In newsgroup: linux.dev.kernel
>
> Daniel Quinlan originally maintained this, now it is orphaned.  His endian
> patch, which implemented the correct behavior according to the docs (which
> basically listed always do little endian as a todo), was dropped.
> 
> We have been maintaining this patch on our kernel, but it really should go
> in - I don't want to spend a ton of time like I did last time to have it
> dropped again, however - is anyone thinking of maintaining cramfs?  What
> are the chances of the endian fix going in if I submit it again?  (if even
> the former maintainer had no success).  I would maintain cramfs if desired
> - it hasn't really changed in a long time except in regards to higher
> level fs changes.
> 

I think Al Viro has been doing a rewrite.  You may want to check with him.

	-hpa
-- 
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
If you send me mail in HTML format I will assume it's spam.
"Unix gives you enough rope to shoot yourself in the foot."
Architectures needed: ia64 m68k mips64 ppc ppc64 s390 s390x sh v850 x86-64

Re: RAMFS, CRAMFS and JFFS2(was Re: /linuxrc query)

[David Woodhouse]

On Fri, 23 Mar 2001, Amit D Chaudhary wrote:

> 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.

I'm not aware of any bugs being found in cramfs recently - unless you 
wanted to use it on Alpha (or anything else where PAGE_SIZE != the 
hard-coded 4096 in mkcramfs.c).

I wouldn't avoid it for those reasons - although if you're _really_ short 
of flash space, the same argument applies as for JFFS2 - a single 
compression stream (tar.gz) will be smaller than compressing individual 
pages like JFFS2 and cramfs do.


> I might be wrong and hence would welcome any suggestions.

Given your stated constraints - you're very short of flash and don't care
too much about the RAM you use, you've may have made the same choice I
would have done.

Bearing in mind that you have to take into account the overhead of the 
initrd which does the untarring - what's the total size of the initrd + 
tarball on the flash, and what size would the corresponding cramfs be?

If you could fit your root filesystem into a cramfs on the flash, I'd do
that instead and use ramfs for the parts which need to be writeable.


-- 
dwmw2

Re: CRAMFS

[Bjorn Wesen]

On Fri, 23 Mar 2001, David Woodhouse wrote:
> > 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.

Ok, ramfs is really simple, but heck, cramfs is not much more complex :)
It's as simple a flash-filesystem as you can get.

I don't know why the comparision is made though, they are used for two
completely different things... ramfs is for temporary file storage, cramfs
is for immutable files stored on flash. Each by itself is quite optimal
for what it's designed for, isn't it ?

> I'm not aware of any bugs being found in cramfs recently - unless you 
> wanted to use it on Alpha (or anything else where PAGE_SIZE != the 
> hard-coded 4096 in mkcramfs.c).

I committed a patch that disappeared that added the choice of page size
(trivial yes :), we have PAGE_SIZE == 8192 on our systems. Works fine.

> I wouldn't avoid it for those reasons - although if you're _really_ short 
> of flash space, the same argument applies as for JFFS2 - a single 
> compression stream (tar.gz) will be smaller than compressing individual 
> pages like JFFS2 and cramfs do.

Here are some results from a quite mixed filesystem:

[bjornw@godzilla linux]$ ls -l cram*
-rw-r--r--   1 bjornw   users     1179648 Mar 23 22:38 cram32768
-rw-r--r--   1 bjornw   users     1282048 Mar 23 22:38 cram4096
-rw-r--r--   1 bjornw   users     1220608 Mar 23 22:38 cram8192

(the numbers correspond to blocksize)

There's not any big difference here. 

With bigger files though, the difference get larger. YMMV.

Notice that you can change cramfs so it uses a blocksize that is bigger
than PAGE_SIZE, of course, if it really is necessary. You'll get worse
performance at run-time though since you need to cache the page and hope
for read-ahead or similar (you can stuff the pages in the page-cache even
if they are not requested for example).

-BW

Re: CRAMFS

[Amit D Chaudhary]

> I don't know why the comparision is made though, they are used for two
> completely different things... ramfs is for temporary file storage, cramfs
> is for immutable files stored on flash. Each by itself is quite optimal
> for what it's designed for, isn't it ?

Exactly. My mistake earlier to assume cramfs was "compressed ramfs"! ;-)
I should compare it to the tar.gz option and JFFS2. Will do in the next 
evaluation.
This will be more of a replace initrd+custom /linuxrc with a 
CRAMFS-based rootfs on a flash device assuming CRAMFS can be directly 
read by kernel\init for getting the rootfs. Ditto for JFFS2

Also, the platform is PPC, IBM 405GP to be precise.

Regards
Amit