| rjw | 1f88458 | 2022-01-06 17:20:42 +0800 | [diff] [blame] | 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_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. |