Blame view

kernel/linux-rt-4.4.41/Documentation/filesystems/cramfs.txt 2.54 KB
5113f6f70   김현기   kernel add
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
  
  	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.
  
  
  Usage Notes
  -----------
  
  File sizes are limited to less than 16MB.
  
  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 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.)
  
  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.
  
  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.
  
  
  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.