The compressed ROM filesystem (or cramfs) is a read-only Linuxfilesystem designed for simplicity and space-efficiency. It is mainly used in embedded systems and small-footprint systems. Tux, a penguin, is the official Linux mascot. ... See Filing system for this term as it is used in libraries and offices In computing, a file system is a method for storing and organizing computer files and the data they contain to make it easy to find and access them. ... An embedded system is a special-purpose computer system, which is completely encapsulated by the device it controls. ...
Some Linux distributions also appear to use cramfs as a file system for initial ramdisks (recent versions of Debian in particular) and installation images (SuSE in particular), where there may be onerous space constraints. Unlike a compressed image of a conventional filesystem, a cramfs image does not have to be uncompressed first and can be used as-is, compressed. A Linux distribution or GNU/Linux distribution (or a distro) is a Unix-like operating system comprising software components such as the Linux kernel, the GNU toolchain, and assorted free and open source software. ...
Files on cramfs file systems are compressed file one page at a time to allow random read access. The meta-data is not compressed, but is expressed in a terse representation that is more space-efficient than conventional filesystems.
cramfs is intentionally read-only to simplify its design: random write access for compressed files is difficult to implement. Instead, it ships with a utility (mkcramfs) to pack files into new cramfs images.
Limits
File sizes are limited to less than 16MB.
Maximum filesystem size is a little over 256MB; the last file on the filesystem is allowed to extend past 256MB.
Only the low 8 bits of gid are stored. The current version of mkcramfs simply truncates to 8 bits, which is a potential security issue.
Hard links are supported, but hard linked files will still have a link count of 1 in the cramfs image.
Cramfs directories have no `.' or `..' entries. Directories (like every other file on cramfs) always have a link count of 1(however, there's no need to use -noleaf in `find').
No timestamps are stored in a cramfs, so these default to the epoch (1970 GMT). Recently-accessed files may have updated timestamps, but the update lasts only as long as the inode is cached in memory, after which the timestamp reverts to 1970, i.e. moves backwards in time.
Currently, cramfs must be written and read with architectures of the same endianness, and can be read only by kernels with the same cramfs page size. At least the latter of these is a bug, but it hasn't been decided what the best fix is.
1 2 Cramfs - cram a filesystem onto a small ROM 3 4 cramfs is designed to be simple and small, and to compress things well.
Recently-accessed files may have updated timestamps, but 37 the update lasts only as long as the inode is cached in memory, after 38 which the timestamp reverts to 1970, i.e.
At least the latter of these is a bug, but it hasn't been 43 decided what the best fix is. For the moment if you have larger pages 44 you can just change the #define in mkcramfs.c, so long as you don't 45 mind the filesystem becoming unreadable to future kernels.
Date: Mon, 15 Jan 2001 03:33:31 -0800 To: linux-kernel@vger.kernel.org Subject: cramfsfilesystem patch for 2.4.0 From: Daniel Quinlan Here is an update of my patch for the cramfsfilesystem for 2.4.0 with a few minor additions.
It's backward-compatible and only modifies cramfs code (aside from adding cramfs to struct super_block).
All old cramfs images will still work and new cramfs images are mountable on old kernels if you avoid using new features: holes (holes require kernel 2.3.39 or later) and padding for a boot sector (you should have a new kernel in that case).
Feeds |
Contact