Commit | Line | Data |
---|---|---|
1da177e4 LT |
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. | |
5 | ||
6 | It uses the zlib routines to compress a file one page at a time, and | |
7 | allows random page access. The meta-data is not compressed, but is | |
8 | expressed in a very terse representation to make it use much less | |
9 | diskspace than traditional filesystems. | |
10 | ||
11 | You can't write to a cramfs filesystem (making it compressible and | |
12 | compact also makes it _very_ hard to update on-the-fly), so you have to | |
13 | create the disk image with the "mkcramfs" utility. | |
14 | ||
15 | ||
16 | Usage Notes | |
17 | ----------- | |
18 | ||
19 | File sizes are limited to less than 16MB. | |
20 | ||
21 | Maximum filesystem size is a little over 256MB. (The last file on the | |
22 | filesystem is allowed to extend past 256MB.) | |
23 | ||
24 | Only the low 8 bits of gid are stored. The current version of | |
25 | mkcramfs simply truncates to 8 bits, which is a potential security | |
26 | issue. | |
27 | ||
28 | Hard links are supported, but hard linked files | |
29 | will still have a link count of 1 in the cramfs image. | |
30 | ||
31 | Cramfs directories have no `.' or `..' entries. Directories (like | |
32 | every other file on cramfs) always have a link count of 1. (There's | |
33 | no need to use -noleaf in `find', btw.) | |
34 | ||
35 | No timestamps are stored in a cramfs, so these default to the epoch | |
36 | (1970 GMT). 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. moves backwards in time. | |
39 | ||
40 | Currently, cramfs must be written and read with architectures of the | |
41 | same endianness, and can be read only by kernels with PAGE_CACHE_SIZE | |
42 | == 4096. 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. | |
46 | ||
47 | ||
48 | For /usr/share/magic | |
49 | -------------------- | |
50 | ||
51 | 0 ulelong 0x28cd3d45 Linux cramfs offset 0 | |
52 | >4 ulelong x size %d | |
53 | >8 ulelong x flags 0x%x | |
54 | >12 ulelong x future 0x%x | |
55 | >16 string >\0 signature "%.16s" | |
56 | >32 ulelong x fsid.crc 0x%x | |
57 | >36 ulelong x fsid.edition %d | |
58 | >40 ulelong x fsid.blocks %d | |
59 | >44 ulelong x fsid.files %d | |
60 | >48 string >\0 name "%.16s" | |
61 | 512 ulelong 0x28cd3d45 Linux cramfs offset 512 | |
62 | >516 ulelong x size %d | |
63 | >520 ulelong x flags 0x%x | |
64 | >524 ulelong x future 0x%x | |
65 | >528 string >\0 signature "%.16s" | |
66 | >544 ulelong x fsid.crc 0x%x | |
67 | >548 ulelong x fsid.edition %d | |
68 | >552 ulelong x fsid.blocks %d | |
69 | >556 ulelong x fsid.files %d | |
70 | >560 string >\0 name "%.16s" | |
71 | ||
72 | ||
73 | Hacker Notes | |
74 | ------------ | |
75 | ||
76 | See fs/cramfs/README for filesystem layout and implementation notes. |