Cramfs - cram a filesystem onto a small ROMcramfs is designed to be simple and small, and to compress things well. It uses the zlib routines to compress a file one page at a time, andallows random page access.  The meta-data is not compressed, but isexpressed in a very terse representation to make it use much lessdiskspace than traditional filesystems. You can't write to a cramfs filesystem (making it compressible andcompact also makes it _very_ hard to update on-the-fly), so you have tocreate the disk image with the "mkcramfs" utility in scripts/cramfs.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.)  (Comments in mkcramfs.csuggest that ROM sizes may be limited to 64MB, though that's not alimitation in cramfs code.)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 in `find', 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_CACHE_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.Hacker Notes------------See fs/cramfs/README for filesystem layout and implementation notes.