| 1 |
1275 |
phoenix |
|
| 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 |
|
|
|
| 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.
|
