1.. SPDX-License-Identifier: GPL-2.0 2 3The Contents of inode.i_block 4------------------------------ 5 6Depending on the type of file an inode describes, the 60 bytes of 7storage in ``inode.i_block`` can be used in different ways. In general, 8regular files and directories will use it for file block indexing 9information, and special files will use it for special purposes. 10 11Symbolic Links 12~~~~~~~~~~~~~~ 13 14The target of a symbolic link will be stored in this field if the target 15string is less than 60 bytes long. Otherwise, either extents or block 16maps will be used to allocate data blocks to store the link target. 17 18Direct/Indirect Block Addressing 19~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 20 21In ext2/3, file block numbers were mapped to logical block numbers by 22means of an (up to) three level 1-1 block map. To find the logical block 23that stores a particular file block, the code would navigate through 24this increasingly complicated structure. Notice that there is neither a 25magic number nor a checksum to provide any level of confidence that the 26block isn't full of garbage. 27 28.. ifconfig:: builder != 'latex' 29 30 .. include:: blockmap.rst 31 32.. ifconfig:: builder == 'latex' 33 34 [Table omitted because LaTeX doesn't support nested tables.] 35 36Note that with this block mapping scheme, it is necessary to fill out a 37lot of mapping data even for a large contiguous file! This inefficiency 38led to the creation of the extent mapping scheme, discussed below. 39 40Notice also that a file using this mapping scheme cannot be placed 41higher than 2^32 blocks. 42 43Extent Tree 44~~~~~~~~~~~ 45 46In ext4, the file to logical block map has been replaced with an extent 47tree. Under the old scheme, allocating a contiguous run of 1,000 blocks 48requires an indirect block to map all 1,000 entries; with extents, the 49mapping is reduced to a single ``struct ext4_extent`` with 50``ee_len = 1000``. If flex_bg is enabled, it is possible to allocate 51very large files with a single extent, at a considerable reduction in 52metadata block use, and some improvement in disk efficiency. The inode 53must have the extents flag (0x80000) flag set for this feature to be in 54use. 55 56Extents are arranged as a tree. Each node of the tree begins with a 57``struct ext4_extent_header``. If the node is an interior node 58(``eh.eh_depth`` > 0), the header is followed by ``eh.eh_entries`` 59instances of ``struct ext4_extent_idx``; each of these index entries 60points to a block containing more nodes in the extent tree. If the node 61is a leaf node (``eh.eh_depth == 0``), then the header is followed by 62``eh.eh_entries`` instances of ``struct ext4_extent``; these instances 63point to the file's data blocks. The root node of the extent tree is 64stored in ``inode.i_block``, which allows for the first four extents to 65be recorded without the use of extra metadata blocks. 66 67The extent tree header is recorded in ``struct ext4_extent_header``, 68which is 12 bytes long: 69 70.. list-table:: 71 :widths: 8 8 24 40 72 :header-rows: 1 73 74 * - Offset 75 - Size 76 - Name 77 - Description 78 * - 0x0 79 - __le16 80 - eh_magic 81 - Magic number, 0xF30A. 82 * - 0x2 83 - __le16 84 - eh_entries 85 - Number of valid entries following the header. 86 * - 0x4 87 - __le16 88 - eh_max 89 - Maximum number of entries that could follow the header. 90 * - 0x6 91 - __le16 92 - eh_depth 93 - Depth of this extent node in the extent tree. 0 = this extent node 94 points to data blocks; otherwise, this extent node points to other 95 extent nodes. The extent tree can be at most 5 levels deep: a logical 96 block number can be at most ``2^32``, and the smallest ``n`` that 97 satisfies ``4*(((blocksize - 12)/12)^n) >= 2^32`` is 5. 98 * - 0x8 99 - __le32 100 - eh_generation 101 - Generation of the tree. (Used by Lustre, but not standard ext4). 102 103Internal nodes of the extent tree, also known as index nodes, are 104recorded as ``struct ext4_extent_idx``, and are 12 bytes long: 105 106.. list-table:: 107 :widths: 8 8 24 40 108 :header-rows: 1 109 110 * - Offset 111 - Size 112 - Name 113 - Description 114 * - 0x0 115 - __le32 116 - ei_block 117 - This index node covers file blocks from 'block' onward. 118 * - 0x4 119 - __le32 120 - ei_leaf_lo 121 - Lower 32-bits of the block number of the extent node that is the next 122 level lower in the tree. The tree node pointed to can be either another 123 internal node or a leaf node, described below. 124 * - 0x8 125 - __le16 126 - ei_leaf_hi 127 - Upper 16-bits of the previous field. 128 * - 0xA 129 - __u16 130 - ei_unused 131 - 132 133Leaf nodes of the extent tree are recorded as ``struct ext4_extent``, 134and are also 12 bytes long: 135 136.. list-table:: 137 :widths: 8 8 24 40 138 :header-rows: 1 139 140 * - Offset 141 - Size 142 - Name 143 - Description 144 * - 0x0 145 - __le32 146 - ee_block 147 - First file block number that this extent covers. 148 * - 0x4 149 - __le16 150 - ee_len 151 - Number of blocks covered by extent. If the value of this field is <= 152 32768, the extent is initialized. If the value of the field is > 32768, 153 the extent is uninitialized and the actual extent length is ``ee_len`` - 154 32768. Therefore, the maximum length of a initialized extent is 32768 155 blocks, and the maximum length of an uninitialized extent is 32767. 156 * - 0x6 157 - __le16 158 - ee_start_hi 159 - Upper 16-bits of the block number to which this extent points. 160 * - 0x8 161 - __le32 162 - ee_start_lo 163 - Lower 32-bits of the block number to which this extent points. 164 165Prior to the introduction of metadata checksums, the extent header + 166extent entries always left at least 4 bytes of unallocated space at the 167end of each extent tree data block (because (2^x % 12) >= 4). Therefore, 168the 32-bit checksum is inserted into this space. The 4 extents in the 169inode do not need checksumming, since the inode is already checksummed. 170The checksum is calculated against the FS UUID, the inode number, the 171inode generation, and the entire extent block leading up to (but not 172including) the checksum itself. 173 174``struct ext4_extent_tail`` is 4 bytes long: 175 176.. list-table:: 177 :widths: 8 8 24 40 178 :header-rows: 1 179 180 * - Offset 181 - Size 182 - Name 183 - Description 184 * - 0x0 185 - __le32 186 - eb_checksum 187 - Checksum of the extent block, crc32c(uuid+inum+igeneration+extentblock) 188 189Inline Data 190~~~~~~~~~~~ 191 192If the inline data feature is enabled for the filesystem and the flag is 193set for the inode, it is possible that the first 60 bytes of the file 194data are stored here. 195