18012Sjulian.. SPDX-License-Identifier: GPL-2.0 212090Sgibbs 38012SjulianThe Contents of inode.i_block 415329Sgibbs------------------------------ 512090Sgibbs 615329SgibbsDepending on the type of file an inode describes, the 60 bytes of 712090Sgibbsstorage in ``inode.i_block`` can be used in different ways. In general, 812090Sgibbsregular files and directories will use it for file block indexing 912090Sgibbsinformation, and special files will use it for special purposes. 1012090Sgibbs 1112090SgibbsSymbolic Links 1212090Sgibbs~~~~~~~~~~~~~~ 1312090Sgibbs 1412090SgibbsThe target of a symbolic link will be stored in this field if the target 1512090Sgibbsstring is less than 60 bytes long. Otherwise, either extents or block 1615329Sgibbsmaps will be used to allocate data blocks to store the link target. 1715329Sgibbs 188012SjulianDirect/Indirect Block Addressing 1915329Sgibbs~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 2015329Sgibbs 2115329SgibbsIn ext2/3, file block numbers were mapped to logical block numbers by 2215329Sgibbsmeans of an (up to) three level 1-1 block map. To find the logical block 2315329Sgibbsthat stores a particular file block, the code would navigate through 2415329Sgibbsthis increasingly complicated structure. Notice that there is neither a 2515329Sgibbsmagic number nor a checksum to provide any level of confidence that the 2615329Sgibbsblock isn't full of garbage. 2715329Sgibbs 2815329Sgibbs.. ifconfig:: builder != 'latex' 2915329Sgibbs 3015329Sgibbs .. include:: blockmap.rst 3150477Speter 328012Sjulian.. ifconfig:: builder == 'latex' 338012Sjulian 3412090Sgibbs [Table omitted because LaTeX doesn't support nested tables.] 3512090Sgibbs 368012SjulianNote that with this block mapping scheme, it is necessary to fill out a 3713691Sgibbslot of mapping data even for a large contiguous file! This inefficiency 3812090Sgibbsled to the creation of the extent mapping scheme, discussed below. 3912122Sgibbs 4012122SgibbsNotice also that a file using this mapping scheme cannot be placed 4112122Sgibbshigher than 2^32 blocks. 4212122Sgibbs 4312122SgibbsExtent Tree 4412122Sgibbs~~~~~~~~~~~ 4512090Sgibbs 4623855SjoergIn ext4, the file to logical block map has been replaced with an extent 4712090Sgibbstree. Under the old scheme, allocating a contiguous run of 1,000 blocks 4813691Sgibbsrequires an indirect block to map all 1,000 entries; with extents, the 4912090Sgibbsmapping is reduced to a single ``struct ext4_extent`` with 5045791Speter``ee_len = 1000``. If flex_bg is enabled, it is possible to allocate 5145791Spetervery large files with a single extent, at a considerable reduction in 5245791Spetermetadata block use, and some improvement in disk efficiency. The inode 5345791Spetermust have the extents flag (0x80000) flag set for this feature to be in 5445791Speteruse. 5545791Speter 5649360SmdoddExtents are arranged as a tree. Each node of the tree begins with a 5749360Smdodd``struct ext4_extent_header``. If the node is an interior node 5849360Smdodd(``eh.eh_depth`` > 0), the header is followed by ``eh.eh_entries`` 5945791Speterinstances of ``struct ext4_extent_idx``; each of these index entries 6045791Speterpoints to a block containing more nodes in the extent tree. If the node 6145791Speteris a leaf node (``eh.eh_depth == 0``), then the header is followed by 62102177Smux``eh.eh_entries`` instances of ``struct ext4_extent``; these instances 63102177Smuxpoint to the file's data blocks. The root node of the extent tree is 6445791Speterstored in ``inode.i_block``, which allows for the first four extents to 6545791Speterbe recorded without the use of extra metadata blocks. 6645791Speter 6745791SpeterThe extent tree header is recorded in ``struct ext4_extent_header``, 6845791Speterwhich is 12 bytes long: 69102177Smux 70102177Smux.. list-table:: 7192739Salfred :widths: 8 8 24 40 7245791Speter :header-rows: 1 7313691Sgibbs 7413691Sgibbs * - Offset 7513691Sgibbs - Size 7613691Sgibbs - Name 7713691Sgibbs - Description 7892739Salfred * - 0x0 7992739Salfred - __le16 8013691Sgibbs - eh_magic 8112090Sgibbs - 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