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.
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 == 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
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.
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:
$ 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
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:
# 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
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:
# df /mnt
Filesystem 1k-blocks Used Available Use% Mounted on
/dev/mtdblock3 0 0 0 - /mnt
