Usage Notes¶

File sizes are limited to less than 16MB.

Maximum filesystem size is a little over 256MB. (The last file on thefilesystem is allowed to extend past 256MB.)

Only the low 8 bits of gid are stored. The current version ofmkcramfs simply truncates to 8 bits, which is a potential securityissue.

Hard links are supported, but hard linked fileswill still have a link count of 1 in the cramfs image.

Cramfs directories have no. or.. entries. Directories (likeevery other file on cramfs) always have a link count of 1. (There’sno need to use -noleaf infind, btw.)

No timestamps are stored in a cramfs, so these default to the epoch(1970 GMT). Recently-accessed files may have updated timestamps, butthe update lasts only as long as the inode is cached in memory, afterwhich the timestamp reverts to 1970, i.e. moves backwards in time.

Currently, cramfs must be written and read with architectures of thesame endianness, and can be read only by kernels with PAGE_SIZE== 4096. At least the latter of these is a bug, but it hasn’t beendecided what the best fix is. For the moment if you have larger pagesyou can just change the #define in mkcramfs.c, so long as you don’tmind the filesystem becoming unreadable to future kernels.

Memory Mapped cramfs image¶

The CRAMFS_MTD Kconfig option adds support for loading data directly froma physical linear memory range (usually non volatile memory like Flash)instead of going through the block device layer. This saves some memorysince no intermediate buffering is necessary to hold the data beforedecompressing.

And when data blocks are kept uncompressed and properly aligned, they willautomatically be mapped directly into user space whenever possible providingeXecute-In-Place (XIP) from ROM of read-only segments. Data segments mappedread-write (hence they have to be copied to RAM) may still be compressed inthe cramfs image in the same file along with non compressed read-onlysegments. Both MMU and no-MMU systems are supported. This is particularlyhandy for tiny embedded systems with very tight memory constraints.

The location of the cramfs image in memory is system dependent. You mustknow the proper physical address where the cramfs image is located andconfigure an MTD device for it. Also, that MTD device must be supportedby a map driver that implements the “point” method. Examples of suchMTD drivers are cfi_cmdset_0001 (Intel/Sharp CFI flash) or physmap(Flash device in physical memory map). MTD partitions based on such devicesare fine too. Then that device should be specified with the “mtd:” prefixas the mount device argument. For example, to mount the MTD device named“fs_partition” on the /mnt directory:

$ mount -t cramfs mtd:fs_partition /mnt

To boot a kernel with this as root filesystem, suffice to specifysomething like “root=mtd:fs_partition” on the kernel command line.

Tools¶

A version of mkcramfs that can take advantage of the latest capabilitiesdescribed above can be found here:

https://github.com/npitre/cramfs-tools

For /usr/share/magic¶

Hacker Notes¶

See fs/cramfs/README for filesystem layout and implementation notes.