0001 .. SPDX-License-Identifier: GPL-2.0
0002
0003 Inline Data
0004 -----------
0005
0006 The inline data feature was designed to handle the case that a file's
0007 data is so tiny that it readily fits inside the inode, which
0008 (theoretically) reduces disk block consumption and reduces seeks. If the
0009 file is smaller than 60 bytes, then the data are stored inline in
0010 ``inode.i_block``. If the rest of the file would fit inside the extended
0011 attribute space, then it might be found as an extended attribute
0012 “system.data” within the inode body (“ibody EA”). This of course
0013 constrains the amount of extended attributes one can attach to an inode.
0014 If the data size increases beyond i_block + ibody EA, a regular block
0015 is allocated and the contents moved to that block.
0016
0017 Pending a change to compact the extended attribute key used to store
0018 inline data, one ought to be able to store 160 bytes of data in a
0019 256-byte inode (as of June 2015, when i_extra_isize is 28). Prior to
0020 that, the limit was 156 bytes due to inefficient use of inode space.
0021
0022 The inline data feature requires the presence of an extended attribute
0023 for “system.data”, even if the attribute value is zero length.
0024
0025 Inline Directories
0026 ~~~~~~~~~~~~~~~~~~
0027
0028 The first four bytes of i_block are the inode number of the parent
0029 directory. Following that is a 56-byte space for an array of directory
0030 entries; see ``struct ext4_dir_entry``. If there is a “system.data”
0031 attribute in the inode body, the EA value is an array of
0032 ``struct ext4_dir_entry`` as well. Note that for inline directories, the
0033 i_block and EA space are treated as separate dirent blocks; directory
0034 entries cannot span the two.
0035
0036 Inline directory entries are not checksummed, as the inode checksum
0037 should protect all inline data contents.
