Free-space bitmap

The simplest form of free-space bitmap is a bit array, i.e. a block of bits. In this example, a zero would indicate a free sector, while a one indicates a sector in use. Each sector would be of fixed size. For explanatory purposes, we will use a 4 GiB hard drive with 4096-byte sectors and assume that the bitmap itself is stored elsewhere. The example disk would require 1,048,576 bits, one for each sector, or 128 KiB. Increasing the size of the drive will proportionately increase the size of the bitmap, while multiplying the sector size will produce a proportionate reduction. When the operating system (OS) needs to write a file, it will scan the bitmap until it finds enough free locations to fit the file. If a 12 KiB file were stored on the example drive, three zero bits would be found, changed to ones, and the data would be written across the three sectors represented by those bits. If the file were subsequently truncated down to 8 KiB, the final sector's bit would be set back to zero, indicating that it is again available for use. Advantages • Simple: Each bit directly corresponds to a sector. • Fast random-access allocation check: Checking whether a sector is free is as simple as checking the corresponding bit. • Fast deletion: Data need not be overwritten on delete; flipping the corresponding bit is sufficient. • Fixed cost: Both an advantage and disadvantage. Other techniques to store free-space information have a variable amount of overhead depending on the number and size of the free-space extents. Bitmaps can never do as well as other techniques in their respective ideal circumstances, but don't suffer pathological cases either. Since the bitmap never grows, shrinks or moves, fewer lookups are required to find the desired information. • Low storage overhead as a fraction of the drive size: Even with relatively small sector sizes, the storage space required for the bitmap is small. A 2 TB drive could be fully represented with a mere 64 MB bitmap (for 4096-byte sectors). Disadvantages • Wasteful on larger disks: The simplistic design starts wasting large amounts of space (in an absolute sense) for extremely large volumes. • Poor scalability: While the size remains negligible as a fraction of the disk size, finding free space becomes slower as the disk fills. If the bitmap is larger than available memory, performance drops precipitously on all operations. • Fragmentation: If free sectors are taken as they are found, drives with frequent file creation and deletion will rapidly become fragmented. If the search attempts to find contiguous blocks, finding free space becomes much slower for even moderately full disks. Fragmented data also slows down reading speeds on mechanical hard drives due to seeking latency of the magnetic head, though this is not an issue on flash memory. ==Advanced techniques==

As the drive size grows, the amount of time needed to scan for free space can become unreasonable. To address this, real-world implementations of free-space bitmaps will find ways to centralize information on free space. One approach is to split the bitmap into many chunks. A separate array then stores the number of free sectors in each chunk, so chunks with insufficient space can be easily skipped over, and the total amount of free space is easier to compute. Finding free space now entails searching the summary array first, then searching the associated bitmap chunk for the exact sectors available. This approach drastically reduces the cost of finding free space, but it doesn't help with the process of freeing space. If the combined size of the summary array and bitmap is greater than can readily be stored in memory, and a large number of files with scattered sectors are freed, an enormous amount of disk access is necessary to find all the sectors, decrement the summary counter and flip the bits back to zero. This greatly reduces the benefits of the bitmap, as it is no longer performing its function of summarizing the free space rapidly without reading from the disk. ==See also==