57 lines · plain
1.. SPDX-License-Identifier: GPL-2.02 3Block and Inode Allocation Policy4---------------------------------5 6ext4 recognizes (better than ext3, anyway) that data locality is7generally a desirably quality of a filesystem. On a spinning disk,8keeping related blocks near each other reduces the amount of movement9that the head actuator and disk must perform to access a data block,10thus speeding up disk IO. On an SSD there of course are no moving parts,11but locality can increase the size of each transfer request while12reducing the total number of requests. This locality may also have the13effect of concentrating writes on a single erase block, which can speed14up file rewrites significantly. Therefore, it is useful to reduce15fragmentation whenever possible.16 17The first tool that ext4 uses to combat fragmentation is the multi-block18allocator. When a file is first created, the block allocator19speculatively allocates 8KiB of disk space to the file on the assumption20that the space will get written soon. When the file is closed, the21unused speculative allocations are of course freed, but if the22speculation is correct (typically the case for full writes of small23files) then the file data gets written out in a single multi-block24extent. A second related trick that ext4 uses is delayed allocation.25Under this scheme, when a file needs more blocks to absorb file writes,26the filesystem defers deciding the exact placement on the disk until all27the dirty buffers are being written out to disk. By not committing to a28particular placement until it's absolutely necessary (the commit timeout29is hit, or sync() is called, or the kernel runs out of memory), the hope30is that the filesystem can make better location decisions.31 32The third trick that ext4 (and ext3) uses is that it tries to keep a33file's data blocks in the same block group as its inode. This cuts down34on the seek penalty when the filesystem first has to read a file's inode35to learn where the file's data blocks live and then seek over to the36file's data blocks to begin I/O operations.37 38The fourth trick is that all the inodes in a directory are placed in the39same block group as the directory, when feasible. The working assumption40here is that all the files in a directory might be related, therefore it41is useful to try to keep them all together.42 43The fifth trick is that the disk volume is cut up into 128MB block44groups; these mini-containers are used as outlined above to try to45maintain data locality. However, there is a deliberate quirk -- when a46directory is created in the root directory, the inode allocator scans47the block groups and puts that directory into the least heavily loaded48block group that it can find. This encourages directories to spread out49over a disk; as the top-level directory/file blobs fill up one block50group, the allocators simply move on to the next block group. Allegedly51this scheme evens out the loading on the block groups, though the author52suspects that the directories which are so unlucky as to land towards53the end of a spinning drive get a raw deal performance-wise.54 55Of course if all of these mechanisms fail, one can always use e4defrag56to defragment files.57