FlashFilesystemsCRAMFS < DULG

%SECTION0{name=FlashFilesystemCRAMFS}% Compressed ROM Filesystem

In some cases it is sufficent to have read-only access to some files,
and if the files are big enough it becomes desirable to use some
method of compression. The Compressed ROM Filesystem *CramFs* might
be a solution here.

%X% Please note that CramFs has - beside the fact that it is a
read-only filesystem - some severe limitations (like missing support
for timestamps, hard links, and 16/32 bit uid/gids), but there are
many situations in Embedded Systems where it's still useful.

To create a CramFs filesystem a special tool
=mkcramfs= is used to create a file which contains
the CramFs image. Note that the CramFs filesystem can be written and
read only by kernels with PAGE_CACHE_SIZE <nop>=<nop>= 4096, and some versions
of the =mkcramfs= program may have other
restrictions like that the filesystem must be written and read with
architectures of the same endianness. Especially the endianness
requirement makes it impossible to build the CramFs image on x86 PC
host when you want to use it on a [[PowerPC][Power Architecture]]® target. The endianness
problem has been fixed in the version of =mkcramfs=
that comes with the ELDK.

In some cases you can use a target system running with root
filesystem mounted over NFS to create the CramFs image on the native
system and store it to flash for further use.

%X% Note: The normal version of the =mkcramfs= program
tries to initialize some entries in the filesystem's superblock with
random numbers by reading _/dev/random_; this may
hang permanently on your target because there is not enough input
(like mouse movement) to the entropy pool. You may want to use a
modified version of =mkcramfs= which does not depend
on _/dev/random_.

To create a CramFs image, you put all files you want in the
filesystem into one directory, and then use the
mkcramfs= program as follows:

<verbatim>
$ mkdir /tmp/test
$ cp ... /tmp/test
$ du -sk /tmp/test
64      /tmp/test
$ mkcramfs /tmp/test test.cramfs.img
Super block: 76 bytes
  erase
  eraseall
  mkfs.jffs
  lock
  unlock
Directory data: 176 bytes
-54.96% (-4784 bytes)   erase
-55.46% (-5010 bytes)   eraseall
-51.94% (-8863 bytes)   mkfs.jffs
-58.76% (-4383 bytes)   lock
-59.68% (-4215 bytes)   unlock
Everything: 24 kilobytes
$ ls -l test.cramfs.img
-rw-r--r--    1 wd       users       24576 Nov 10 23:44 test.cramfs.img
</verbatim>

As you can see, the CramFs image _test.cramfs.img_
takes just 24 kB, while the input directory contained 64 kB of data.
Savings of some 60% like in this case are typical CramFs.

Now we write the CramFs image to a partition in flash and test it:

<verbatim>
# cp test.cramfs.img /dev/mtd3
# mount -t cramfs /dev/mtdblock3 /mnt
# mount
/dev/root on / type nfs (rw,v2,rsize=4096,wsize=4096,hard,udp,nolock,addr=10.0.0.2)
proc on /proc type proc (rw)
devpts on /dev/pts type devpts (rw)
/dev/mtdblock3 on /mnt type cramfs (rw)
# ls -l /mnt
total 54
-rwxr-xr-x    1 wd       users        8704 Jan  9 16:32 erase
-rwxr-xr-x    1 wd       users        9034 Jan  1 01:00 eraseall
-rwxr-xr-x    1 wd       users        7459 Jan  1 01:00 lock
-rwxr-xr-x    1 wd       users       17063 Jan  1 01:00 mkfs.jffs
-rwxr-xr-x    1 wd       users        7063 Jan  1 01:00 unlock
</verbatim>

Note that all the timestamps in the CramFs filesyste are bogus, and
so is for instance the output of the =df= command for such
filesystems:

<verbatim>
# df /mnt
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/mtdblock3               0         0         0   -  /mnt
</verbatim>
9.1.3. Second Version of JFFS		1. Abstract		9.2. The TMPFS Virtual Memory Filesystem
Prev		Home		Next