Lines Matching +full:block +full:- +full:size
2 --------------------------
9 All data is currently in host-endian format; neither mkcramfs nor the
10 kernel ever do swabbing. (See section `Block Size' below.)
22 Filename. Not generally null-terminated, but it is
23 null-padded to a multiple of 4 bytes.
25 The order of inode traversal is described as "width-first" (not to be
26 confused with breadth-first); i.e. like depth-first but listing all of
28 same order as `ls -AUR' (but without the /^\..*:$/ directory header
29 lines); put another way, the same order as `find -type d -exec
30 ls -AU1 {} \;'.
34 exist, speeds up user-space directory sorts, etc.
38 regular file of non-zero st_size.
42 (where nblocks = (st_size - 1) / blksize + 1)
43 nblocks * <block>
47 *end* of the i'th <block> (i.e. one past the last byte, which is the
48 same as the start of the (i+1)'th <block> if there is one). The first
49 <block> immediately follows the last <block_pointer> for the file.
56 The block data is not compressed and should be copied verbatim.
59 The <block_pointer> stores the actual block start offset and not
60 its end, shifted right by 2 bits. The block must therefore be
61 aligned to a 4-byte boundary. The block size is either blksize
64 the block data. This is used to allow discontiguous data layout
65 and specific data block alignments e.g. for XIP applications.
68 The order of <file_data>'s is a depth-first descent of the directory
69 tree, i.e. the same order as `find -size +0 \( -type f -o -type l \)
70 -print'.
73 <block>: The i'th <block> is the output of zlib's compress function
74 applied to the i'th blksize-sized chunk of the input data if the
77 (For the last <block> of the file, the input may of course be smaller.)
78 Each <block> may be a different size. (See <block_pointer> above.)
80 <block>s are merely byte-aligned, not generally u32-aligned.
83 <block> may be located anywhere and not necessarily contiguous with
84 the previous/next blocks. In that case it is minimally u32-aligned.
85 If CRAMFS_BLK_FLAG_UNCOMPRESSED is also specified then the size is always
86 blksize except for the last block which is limited by the file length.
88 is not set then the first 2 bytes of the block contains the size of the
89 remaining block data as this cannot be determined from the placement of
94 -----
100 with -z if you want it to create files that can have holes in them.
104 -----
106 The cramfs user-space tools, including mkcramfs and cramfsck, are
113 Block Size
114 ----------
116 (Block size in cramfs refers to the size of input data that is
120 The superblock ought to indicate the block size that the fs was
126 for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in
143 `always use little-endian' (like ext2fs) or `writer chooses
144 endianness; kernel adapts at runtime'. Little-endian wins because of
145 code simplicity and little CPU overhead even on big-endian machines.
149 data, only the superblock, inodes and block pointers.
152 The other part of making cramfs more sharable is choosing a block
153 size. The options are:
175 Option 3 is easy to implement if we don't mind being CPU-inefficient:
176 e.g. get read_folio to decompress to a buffer of size MAX_BLKSIZE (which
182 will disagree. (If it is implemented, then I'll re-use that code in
187 block size, but that just means adding and parsing a -b option.
190 Inode Size
191 ----------