1.. SPDX-License-Identifier: GPL-2.0
2
3Inline Data
4-----------
5
6The inline data feature was designed to handle the case that a file's
7data is so tiny that it readily fits inside the inode, which
8(theoretically) reduces disk block consumption and reduces seeks. If the
9file is smaller than 60 bytes, then the data are stored inline in
10``inode.i_block``. If the rest of the file would fit inside the extended
11attribute space, then it might be found as an extended attribute
12system.data” within the inode body (“ibody EA”). This of course
13constrains the amount of extended attributes one can attach to an inode.
14If the data size increases beyond i_block + ibody EA, a regular block
15is allocated and the contents moved to that block.
16
17Pending a change to compact the extended attribute key used to store
18inline data, one ought to be able to store 160 bytes of data in a
19256-byte inode (as of June 2015, when i_extra_isize is 28). Prior to
20that, the limit was 156 bytes due to inefficient use of inode space.
21
22The inline data feature requires the presence of an extended attribute
23for “system.data”, even if the attribute value is zero length.
24
25Inline Directories
26~~~~~~~~~~~~~~~~~~
27
28The first four bytes of i_block are the inode number of the parent
29directory. Following that is a 56-byte space for an array of directory
30entries; see ``struct ext4_dir_entry``. If there is a “system.data31attribute in the inode body, the EA value is an array of
32``struct ext4_dir_entry`` as well. Note that for inline directories, the
33i_block and EA space are treated as separate dirent blocks; directory
34entries cannot span the two.
35
36Inline directory entries are not checksummed, as the inode checksum
37should protect all inline data contents.
38