Cramfs - cram a filesystem onto a small ROM
cramfs 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, and
allows random page access. The meta-data is not compressed, but is
expressed in a very terse representation to make it use much less
diskspace than traditional filesystems.
You can't write to a cramfs filesystem (making it compressible and
compact also makes it _very_ hard to update on-the-fly), so you have to
create the disk image with the "mkcramfs" utility.
使用了zlib压缩一个文件一次一页，并且允许随机存取。
元数据meta-data并不被压缩。但是以一个非常简洁的方式使得比传统文件系统更为易用。
你不能写入cramfs文件系统，很难升级。用mkcramfs来创建磁盘镜像。
Usage Notes
-----------
File sizes are limited to less than 16MB.
文件大小限制为小于16MB,最大的文件系统大小可以超过256MB一点。
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 image中仍旧有1个链接计数。
Cramfs directories have no `.' or `..' entries. Directories (like
every other file on cramfs) always have a link count of 1. (There's
no need to use -noleaf in `find', btw.)
cramfs的目录，没有 . 和 .. ,目录，比如其他在cramfs中的条目，都有1个1的连接计数。
顺便说一下，没有必要在 find命令中，使用 -noleaf 。
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.
cramfs中，没有时间戳被存储，因此这些默认为新纪元 1970 GMT， 当前可访问的文件可能已经更新了时间戳，但是更新持续仅仅是
结点被缓存在内存中的时间。之后，时间戳可能要会返回到1970年，也就是立即回滚。
Currently, cramfs must be written and read with architectures of the
same 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 been
decided what the best fix is. For the moment if you have larger pages
you can just change the #define in mkcramfs.c, so long as you don't
mind the filesystem becoming unreadable to future kernels.
当前，cramfs 必须以同样的字节顺序写和读，仅仅可以被内核以 PAGE_CACHE_SIZE==4096来读。这可能是个bug，还不知道啥时候能够修复。如果你现在有很大的page，仅仅改变 在 mkcramfs.c中的#define ,只要你不介意文件系统变得莫名其妙的不能识别内核。
For /usr/share/magic
--------------------
0 ulelong 0x28cd3d45 Linux cramfs offset 0
>4 ulelong x size %d
>8 ulelong x flags 0x%x
>12 ulelong x future 0x%x
>16 string >/0 signature "%.16s"
>32 ulelong x fsid.crc 0x%x
>36 ulelong x fsid.edition %d
>40 ulelong x fsid.blocks %d
>44 ulelong x fsid.files %d
>48 string >/0 name "%.16s"
512 ulelong 0x28cd3d45 Linux cramfs offset 512
>516 ulelong x size %d
>520 ulelong x flags 0x%x
>524 ulelong x future 0x%x
>528 string >/0 signature "%.16s"
>544 ulelong x fsid.crc 0x%x
>548 ulelong x fsid.edition %d
>552 ulelong x fsid.blocks %d
>556 ulelong x fsid.files %d
>560 string >/0 name "%.16s"
Hacker Notes
------------
See fs/cramfs/README for filesystem layout and implementation notes.
==============================================================
CC = gcc
CFLAGS = -W -Wall -O2 -g
CPPFLAGS = -I. include当前路径下的头文件。作为cpp flags
LDLIBS = -lz 链接库是lz,LZ是啥？
PROGS = mkcramfs cramfsck 生成的文件，称为PROGS
all: $(PROGS) all： 啥意思呢？
distclean clean: clean是这样的。前面distclean啥意思呢？
rm -f $(PROGS)
.PHONY: all clean
==================================================================
直接make之后。
得到了
mkcramfs cramfsck
=================================================================
Notes on Filesystem Layout
--------------------------
These notes describe what mkcramfs generates. Kernel requirements are
a bit looser, e.g. it doesn't care if theitems are
swapped around (though it does care that directory entries (inodes) in
a given directory are contiguous, as this is used by readdir).
All data is currently in host-endian format; neither mkcramfs nor the
kernel ever do swabbing. (See section `Block Size' below.)
:
: struct cramfs_super (see cramfs_fs.h).
:
For each file:
struct cramfs_inode (see cramfs_fs.h).
Filename. Not generally null-terminated, but it is
null-padded to a multiple of 4 bytes.
The order of inode traversal is described as "width-first" (not to be
confused with breadth-first); i.e. like depth-first but listing all of
a directory's entries before recursing down its subdirectories: the
same order as `ls -AUR' (but without the /^/..*:$/ directory header
lines); put another way, the same order as `find -type d -exec
ls -AU1 {} /;'.
Beginning in 2.4.7, directory entries are sorted. This optimization
allows cramfs_lookup to return more quickly when a filename does not
exist, speeds up user-space directory sorts, etc.
:
Onefor each file that's either a symlink or a
regular file of non-zero st_size.
:
nblocks *
(where nblocks = (st_size - 1) / blksize + 1)
nblocks *
padding to multiple of 4 bytes
The i'thfor a file stores the byte offset of the
*end* of the i'th(i.e. one past the last byte, which is the
same as the start of the (i+1)'thif there is one). The first
immediately follows the lastfor the file.
s are each 32 bits long.
The order of's is a depth-first descent of the directory
tree, i.e. the same order as `find -size +0 /( -type f -o -type l /)
-print'.
: The i'this the output of zlib's compress function
applied to the i'th blksize-sized chunk of the input data.
(For the lastof the file, the input may of course be smaller.)
Eachmay be a different size. (Seeabove.)
s are merely byte-aligned, not generally u32-aligned.
Holes
-----
This kernel supports cramfs holes (i.e. [efficient representation of]
blocks in uncompressed data consisting entirely of NUL bytes), but by
default mkcramfs doesn't test for & create holes, since cramfs in
kernels up to at least 2.3.39 didn't support holes. Run mkcramfs
with -z if you want it to create files that can have holes in them.
Tools
-----
The cramfs user-space tools, including mkcramfs and cramfsck, are
located at .
Future Development
==================
Block Size
----------
(Block size in cramfs refers to the size of input data that is
compressed at a time. It's intended to be somewhere around
PAGE_CACHE_SIZE for cramfs_readpage's convenience.)
The superblock ought to indicate the block size that the fs was
written for, since comments in indicate that
PAGE_CACHE_SIZE may grow in future (if I interpret the comment
correctly).
Currently, mkcramfs #define's PAGE_CACHE_SIZE as 4096 and uses that
for blksize, whereas Linux-2.3.39 uses its PAGE_CACHE_SIZE, which in
turn is defined as PAGE_SIZE (which can be as large as 32KB on arm).
This discrepancy is a bug, though it's not clear which should be
changed.
One option is to change mkcramfs to take its PAGE_CACHE_SIZE from
. Personally I don't like this option, but it does
require the least amount of change: just change `#define
PAGE_CACHE_SIZE (4096)' to `#include '. The disadvantage
is that the generated cramfs cannot always be shared between different
kernels, not even necessarily kernels of the same architecture if
PAGE_CACHE_SIZE is subject to change between kernel versions
(currently possible with arm and ia64).
The remaining options try to make cramfs more sharable.
One part of that is addressing endianness. The two options here are
`always use little-endian' (like ext2fs) or `writer chooses
endianness; kernel adapts at runtime'. Little-endian wins because of
code simplicity and little CPU overhead even on big-endian machines.
The cost of swabbing is changing the code to use the le32_to_cpu
etc. macros as used by ext2fs. We don't need to swab the compressed
data, only the superblock, inodes and block pointers.
The other part of making cramfs more sharable is choosing a block
size. The options are:
1. Always 4096 bytes.
2. Writer chooses blocksize; kernel adapts but rejects blocksize >
PAGE_CACHE_SIZE.
3. Writer chooses blocksize; kernel adapts even to blocksize >
PAGE_CACHE_SIZE.
It's easy enough to change the kernel to use a smaller value than
PAGE_CACHE_SIZE: just make cramfs_readpage read multiple blocks.
The cost of option 1 is that kernels with a larger PAGE_CACHE_SIZE
value don't get as good compression as they can.
The cost of option 2 relative to option 1 is that the code uses
variables instead of #define'd constants. The gain is that people
with kernels having larger PAGE_CACHE_SIZE can make use of that if
they don't mind their cramfs being inaccessible to kernels with
smaller PAGE_CACHE_SIZE values.
Option 3 is easy to implement if we don't mind being CPU-inefficient:
e.g. get readpage to decompress to a buffer of size MAX_BLKSIZE (which
must be no larger than 32KB) and discard what it doesn't need.
Getting readpage to read into all the covered pages is harder.
The main advantage of option 3 over 1, 2, is better compression. The
cost is greater complexity. Probably not worth it, but I hope someone
will disagree. (If it is implemented, then I'll re-use that code in
e2compr.)
Another cost of 2 and 3 over 1 is making mkcramfs use a different
block size, but that just means adding and parsing a -b option.
Inode Size
----------
Given that cramfs will probably be used for CDs etc. as well as just
silicon ROMs, it might make sense to expand the inode a little from
its current 12 bytes. Inodes other than the root inode are followed
by filename, so the expansion doesn't even have to be a multiple of 4
bytes.
