^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 1) Notes on Filesystem Layout
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 2) --------------------------
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 3)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 4) These notes describe what mkcramfs generates. Kernel requirements are
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 5) a bit looser, e.g. it doesn't care if the <file_data> items are
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 6) swapped around (though it does care that directory entries (inodes) in
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 7) a given directory are contiguous, as this is used by readdir).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 8)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 9) All data is currently in host-endian format; neither mkcramfs nor the
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 10) kernel ever do swabbing. (See section `Block Size' below.)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 11)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 12) <filesystem>:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 13) <superblock>
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 14) <directory_structure>
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 15) <data>
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 16)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 17) <superblock>: struct cramfs_super (see cramfs_fs.h).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 18)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 19) <directory_structure>:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 20) For each file:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 21) struct cramfs_inode (see cramfs_fs.h).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 22) Filename. Not generally null-terminated, but it is
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 23) null-padded to a multiple of 4 bytes.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 24)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 25) The order of inode traversal is described as "width-first" (not to be
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 26) confused with breadth-first); i.e. like depth-first but listing all of
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 27) a directory's entries before recursing down its subdirectories: the
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 28) same order as `ls -AUR' (but without the /^\..*:$/ directory header
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 29) lines); put another way, the same order as `find -type d -exec
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 30) ls -AU1 {} \;'.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 31)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 32) Beginning in 2.4.7, directory entries are sorted. This optimization
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 33) allows cramfs_lookup to return more quickly when a filename does not
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 34) exist, speeds up user-space directory sorts, etc.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 35)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 36) <data>:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 37) One <file_data> for each file that's either a symlink or a
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 38) regular file of non-zero st_size.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 39)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 40) <file_data>:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 41) nblocks * <block_pointer>
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 42) (where nblocks = (st_size - 1) / blksize + 1)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 43) nblocks * <block>
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 44) padding to multiple of 4 bytes
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 45)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 46) The i'th <block_pointer> for a file stores the byte offset of the
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 47) *end* of the i'th <block> (i.e. one past the last byte, which is the
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 48) same as the start of the (i+1)'th <block> if there is one). The first
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 49) <block> immediately follows the last <block_pointer> for the file.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 50) <block_pointer>s are each 32 bits long.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 51)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 52) When the CRAMFS_FLAG_EXT_BLOCK_POINTERS capability bit is set, each
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 53) <block_pointer>'s top bits may contain special flags as follows:
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 54)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 55) CRAMFS_BLK_FLAG_UNCOMPRESSED (bit 31):
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 56) The block data is not compressed and should be copied verbatim.
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 57)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 58) CRAMFS_BLK_FLAG_DIRECT_PTR (bit 30):
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 59) The <block_pointer> stores the actual block start offset and not
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 60) its end, shifted right by 2 bits. The block must therefore be
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 61) aligned to a 4-byte boundary. The block size is either blksize
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 62) if CRAMFS_BLK_FLAG_UNCOMPRESSED is also specified, otherwise
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 63) the compressed data length is included in the first 2 bytes of
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 64) the block data. This is used to allow discontiguous data layout
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 65) and specific data block alignments e.g. for XIP applications.
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 66)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 67)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 68) The order of <file_data>'s is a depth-first descent of the directory
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 69) tree, i.e. the same order as `find -size +0 \( -type f -o -type l \)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 70) -print'.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 71)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 72)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 73) <block>: The i'th <block> is the output of zlib's compress function
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 74) applied to the i'th blksize-sized chunk of the input data if the
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 75) corresponding CRAMFS_BLK_FLAG_UNCOMPRESSED <block_ptr> bit is not set,
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 76) otherwise it is the input data directly.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 77) (For the last <block> of the file, the input may of course be smaller.)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 78) Each <block> may be a different size. (See <block_pointer> above.)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 79)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 80) <block>s are merely byte-aligned, not generally u32-aligned.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 81)
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 82) When CRAMFS_BLK_FLAG_DIRECT_PTR is specified then the corresponding
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 83) <block> may be located anywhere and not necessarily contiguous with
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 84) the previous/next blocks. In that case it is minimally u32-aligned.
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 85) If CRAMFS_BLK_FLAG_UNCOMPRESSED is also specified then the size is always
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 86) blksize except for the last block which is limited by the file length.
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 87) If CRAMFS_BLK_FLAG_DIRECT_PTR is set and CRAMFS_BLK_FLAG_UNCOMPRESSED
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 88) is not set then the first 2 bytes of the block contains the size of the
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 89) remaining block data as this cannot be determined from the placement of
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 90) logically adjacent blocks.
fd4f6f2a78aea (Nicolas Pitre 2017-10-12 02:16:11 -0400 91)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 92)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 93) Holes
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 94) -----
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 95)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 96) This kernel supports cramfs holes (i.e. [efficient representation of]
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 97) blocks in uncompressed data consisting entirely of NUL bytes), but by
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 98) default mkcramfs doesn't test for & create holes, since cramfs in
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 99) kernels up to at least 2.3.39 didn't support holes. Run mkcramfs
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 100) with -z if you want it to create files that can have holes in them.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 101)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 102)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 103) Tools
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 104) -----
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 105)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 106) The cramfs user-space tools, including mkcramfs and cramfsck, are
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 107) located at <http://sourceforge.net/projects/cramfs/>.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 108)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 109)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 110) Future Development
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 111) ==================
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 112)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 113) Block Size
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 114) ----------
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 115)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 116) (Block size in cramfs refers to the size of input data that is
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 117) compressed at a time. It's intended to be somewhere around
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 118) PAGE_SIZE for cramfs_readpage's convenience.)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 119)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 120) The superblock ought to indicate the block size that the fs was
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 121) written for, since comments in <linux/pagemap.h> indicate that
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 122) PAGE_SIZE may grow in future (if I interpret the comment
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 123) correctly).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 124)
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 125) Currently, mkcramfs #define's PAGE_SIZE as 4096 and uses that
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 126) for blksize, whereas Linux-2.3.39 uses its PAGE_SIZE, which in
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 127) turn is defined as PAGE_SIZE (which can be as large as 32KB on arm).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 128) This discrepancy is a bug, though it's not clear which should be
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 129) changed.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 130)
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 131) One option is to change mkcramfs to take its PAGE_SIZE from
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 132) <asm/page.h>. Personally I don't like this option, but it does
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 133) require the least amount of change: just change `#define
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 134) PAGE_SIZE (4096)' to `#include <asm/page.h>'. The disadvantage
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 135) is that the generated cramfs cannot always be shared between different
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 136) kernels, not even necessarily kernels of the same architecture if
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 137) PAGE_SIZE is subject to change between kernel versions
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 138) (currently possible with arm and ia64).
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 139)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 140) The remaining options try to make cramfs more sharable.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 141)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 142) One part of that is addressing endianness. The two options here are
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 143) `always use little-endian' (like ext2fs) or `writer chooses
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 144) endianness; kernel adapts at runtime'. Little-endian wins because of
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 145) code simplicity and little CPU overhead even on big-endian machines.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 146)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 147) The cost of swabbing is changing the code to use the le32_to_cpu
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 148) etc. macros as used by ext2fs. We don't need to swab the compressed
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 149) data, only the superblock, inodes and block pointers.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 150)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 151)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 152) The other part of making cramfs more sharable is choosing a block
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 153) size. The options are:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 154)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 155) 1. Always 4096 bytes.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 156)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 157) 2. Writer chooses blocksize; kernel adapts but rejects blocksize >
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 158) PAGE_SIZE.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 159)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 160) 3. Writer chooses blocksize; kernel adapts even to blocksize >
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 161) PAGE_SIZE.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 162)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 163) It's easy enough to change the kernel to use a smaller value than
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 164) PAGE_SIZE: just make cramfs_readpage read multiple blocks.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 165)
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 166) The cost of option 1 is that kernels with a larger PAGE_SIZE
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 167) value don't get as good compression as they can.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 168)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 169) The cost of option 2 relative to option 1 is that the code uses
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 170) variables instead of #define'd constants. The gain is that people
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 171) with kernels having larger PAGE_SIZE can make use of that if
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 172) they don't mind their cramfs being inaccessible to kernels with
ea1754a084760 (Kirill A. Shutemov 2016-04-01 15:29:48 +0300 173) smaller PAGE_SIZE values.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 174)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 175) Option 3 is easy to implement if we don't mind being CPU-inefficient:
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 176) e.g. get readpage to decompress to a buffer of size MAX_BLKSIZE (which
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 177) must be no larger than 32KB) and discard what it doesn't need.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 178) Getting readpage to read into all the covered pages is harder.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 179)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 180) The main advantage of option 3 over 1, 2, is better compression. The
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 181) cost is greater complexity. Probably not worth it, but I hope someone
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 182) will disagree. (If it is implemented, then I'll re-use that code in
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 183) e2compr.)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 184)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 185)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 186) Another cost of 2 and 3 over 1 is making mkcramfs use a different
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 187) block size, but that just means adding and parsing a -b option.
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 188)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 189)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 190) Inode Size
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 191) ----------
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 192)
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 193) Given that cramfs will probably be used for CDs etc. as well as just
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 194) silicon ROMs, it might make sense to expand the inode a little from
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 195) its current 12 bytes. Inodes other than the root inode are followed
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 196) by filename, so the expansion doesn't even have to be a multiple of 4
^1da177e4c3f4 (Linus Torvalds 2005-04-16 15:20:36 -0700 197) bytes.
VisionFive2 Linux kernel
StarFive Tech Linux Kernel for VisionFive (JH7110) boards (mirror)
More than 9999 Commits
32 Branches
54 Tags