.. SPDX-License-Identifier: GPL-2.0 Block and Inode Allocation Policy--------------------------------- ext4 recognizes (better than ext3, anyway) that data locality isgenerally a desirably quality of a filesystem. On a spinning disk,keeping related blocks near each other reduces the amount of movementthat the head actuator and disk must perform to access a data block,thus speeding up disk IO. On an SSD there of course are no moving parts,but locality can increase the size of each transfer request whilereducing the total number of requests. This locality may also have theeffect of concentrating writes on a single erase block, which can speedup file rewrites significantly. Therefore, it is useful to reducefragmentation whenever possible. The first tool that ext4 uses to combat fragmentation is the multi-blockallocator. When a file is first created, the block allocatorspeculatively allocates 8KiB of disk space to the file on the assumptionthat the space will get written soon. When the file is closed, theunused speculative allocations are of course freed, but if thespeculation is correct (typically the case for full writes of smallfiles) then the file data gets written out in a single multi-blockextent. A second related trick that ext4 uses is delayed allocation.Under this scheme, when a file needs more blocks to absorb file writes,the filesystem defers deciding the exact placement on the disk until allthe dirty buffers are being written out to disk. By not committing to aparticular placement until it's absolutely necessary (the commit timeoutis hit, or sync() is called, or the kernel runs out of memory), the hopeis that the filesystem can make better location decisions. The third trick that ext4 (and ext3) uses is that it tries to keep afile's data blocks in the same block group as its inode. This cuts downon the seek penalty when the filesystem first has to read a file's inodeto learn where the file's data blocks live and then seek over to thefile's data blocks to begin I/O operations. The fourth trick is that all the inodes in a directory are placed in thesame block group as the directory, when feasible. The working assumptionhere is that all the files in a directory might be related, therefore itis useful to try to keep them all together. The fifth trick is that the disk volume is cut up into 128MB blockgroups; these mini-containers are used as outlined above to try tomaintain data locality. However, there is a deliberate quirk -- when adirectory is created in the root directory, the inode allocator scansthe block groups and puts that directory into the least heavily loadedblock group that it can find. This encourages directories to spread outover a disk; as the top-level directory/file blobs fill up one blockgroup, the allocators simply move on to the next block group. Allegedlythis scheme evens out the loading on the block groups, though the authorsuspects that the directories which are so unlucky as to land towardsthe end of a spinning drive get a raw deal performance-wise. Of course if all of these mechanisms fail, one can always use e4defragto defragment files.