1 Notes on Filesystem Layout
2 --------------------------
3
4 These notes describe what mkcramfs generates.
5 a bit looser, e.g. it doesn't care if the <fil
6 swapped around (though it does care that direc
7 a given directory are contiguous, as this is u
8
9 All data is currently in host-endian format; n
10 kernel ever do swabbing. (See section `Block
11
12 <filesystem>:
13 <superblock>
14 <directory_structure>
15 <data>
16
17 <superblock>: struct cramfs_super (see cramfs_
18
19 <directory_structure>:
20 For each file:
21 struct cramfs_inode (see cramf
22 Filename. Not generally null-
23 null-padded to a multiple of
24
25 The order of inode traversal is described as "
26 confused with breadth-first); i.e. like depth-
27 a directory's entries before recursing down it
28 same order as `ls -AUR' (but without the /^\..
29 lines); put another way, the same order as `fi
30 ls -AU1 {} \;'.
31
32 Beginning in 2.4.7, directory entries are sort
33 allows cramfs_lookup to return more quickly wh
34 exist, speeds up user-space directory sorts, e
35
36 <data>:
37 One <file_data> for each file that's e
38 regular file of non-zero st_size.
39
40 <file_data>:
41 nblocks * <block_pointer>
42 (where nblocks = (st_size - 1) / blks
43 nblocks * <block>
44 padding to multiple of 4 bytes
45
46 The i'th <block_pointer> for a file stores the
47 *end* of the i'th <block> (i.e. one past the l
48 same as the start of the (i+1)'th <block> if t
49 <block> immediately follows the last <block_po
50 <block_pointer>s are each 32 bits long.
51
52 When the CRAMFS_FLAG_EXT_BLOCK_POINTERS capabi
53 <block_pointer>'s top bits may contain special
54
55 CRAMFS_BLK_FLAG_UNCOMPRESSED (bit 31):
56 The block data is not compressed and s
57
58 CRAMFS_BLK_FLAG_DIRECT_PTR (bit 30):
59 The <block_pointer> stores the actual
60 its end, shifted right by 2 bits. The
61 aligned to a 4-byte boundary. The bloc
62 if CRAMFS_BLK_FLAG_UNCOMPRESSED is als
63 the compressed data length is included
64 the block data. This is used to allow
65 and specific data block alignments e.g
66
67
68 The order of <file_data>'s is a depth-first de
69 tree, i.e. the same order as `find -size +0 \(
70 -print'.
71
72
73 <block>: The i'th <block> is the output of zli
74 applied to the i'th blksize-sized chunk of the
75 corresponding CRAMFS_BLK_FLAG_UNCOMPRESSED <bl
76 otherwise it is the input data directly.
77 (For the last <block> of the file, the input m
78 Each <block> may be a different size. (See <b
79
80 <block>s are merely byte-aligned, not generall
81
82 When CRAMFS_BLK_FLAG_DIRECT_PTR is specified t
83 <block> may be located anywhere and not necess
84 the previous/next blocks. In that case it is m
85 If CRAMFS_BLK_FLAG_UNCOMPRESSED is also specif
86 blksize except for the last block which is lim
87 If CRAMFS_BLK_FLAG_DIRECT_PTR is set and CRAMF
88 is not set then the first 2 bytes of the block
89 remaining block data as this cannot be determi
90 logically adjacent blocks.
91
92
93 Holes
94 -----
95
96 This kernel supports cramfs holes (i.e. [effic
97 blocks in uncompressed data consisting entirel
98 default mkcramfs doesn't test for & create hol
99 kernels up to at least 2.3.39 didn't support h
100 with -z if you want it to create files that ca
101
102
103 Tools
104 -----
105
106 The cramfs user-space tools, including mkcramf
107 located at <http://sourceforge.net/projects/cr
108
109
110 Future Development
111 ==================
112
113 Block Size
114 ----------
115
116 (Block size in cramfs refers to the size of in
117 compressed at a time. It's intended to be som
118 PAGE_SIZE for cramfs_read_folio's convenience.
119
120 The superblock ought to indicate the block siz
121 written for, since comments in <linux/pagemap.
122 PAGE_SIZE may grow in future (if I interpret t
123 correctly).
124
125 Currently, mkcramfs #define's PAGE_SIZE as 409
126 for blksize, whereas Linux-2.3.39 uses its PAG
127 turn is defined as PAGE_SIZE (which can be as
128 This discrepancy is a bug, though it's not cle
129 changed.
130
131 One option is to change mkcramfs to take its P
132 <asm/page.h>. Personally I don't like this op
133 require the least amount of change: just chang
134 PAGE_SIZE (4096)' to `#include <asm/page.h>'.
135 is that the generated cramfs cannot always be
136 kernels, not even necessarily kernels of the s
137 PAGE_SIZE is subject to change between kernel
138 (currently possible with arm and ia64).
139
140 The remaining options try to make cramfs more
141
142 One part of that is addressing endianness. Th
143 `always use little-endian' (like ext2fs) or `w
144 endianness; kernel adapts at runtime'. Little
145 code simplicity and little CPU overhead even o
146
147 The cost of swabbing is changing the code to u
148 etc. macros as used by ext2fs. We don't need
149 data, only the superblock, inodes and block po
150
151
152 The other part of making cramfs more sharable
153 size. The options are:
154
155 1. Always 4096 bytes.
156
157 2. Writer chooses blocksize; kernel adapts b
158 PAGE_SIZE.
159
160 3. Writer chooses blocksize; kernel adapts e
161 PAGE_SIZE.
162
163 It's easy enough to change the kernel to use a
164 PAGE_SIZE: just make cramfs_read_folio read mu
165
166 The cost of option 1 is that kernels with a la
167 value don't get as good compression as they ca
168
169 The cost of option 2 relative to option 1 is t
170 variables instead of #define'd constants. The
171 with kernels having larger PAGE_SIZE can make
172 they don't mind their cramfs being inaccessibl
173 smaller PAGE_SIZE values.
174
175 Option 3 is easy to implement if we don't mind
176 e.g. get read_folio to decompress to a buffer
177 must be no larger than 32KB) and discard what
178 Getting read_folio to read into all the covere
179
180 The main advantage of option 3 over 1, 2, is b
181 cost is greater complexity. Probably not wort
182 will disagree. (If it is implemented, then I'
183 e2compr.)
184
185
186 Another cost of 2 and 3 over 1 is making mkcra
187 block size, but that just means adding and par
188
189
190 Inode Size
191 ----------
192
193 Given that cramfs will probably be used for CD
194 silicon ROMs, it might make sense to expand th
195 its current 12 bytes. Inodes other than the r
196 by filename, so the expansion doesn't even hav
197 bytes.
Linux® is a registered trademark of Linus Torvalds in the United States and other countries.
TOMOYO® is a registered trademark of NTT DATA CORPORATION.