Block Storage & File Organization

• DMA stands for Direct Memory Access.
• With DMA, a device copies data directly between the device and main memory without the CPU copying every byte.
• The driver gives the device a memory address and a length.
• The device then performs the transfer itself.
• This improves performance, but it also bypasses the CPU’s normal memory-management path.

• Normal CPU memory accesses go through the MMU.
• The MMU translates virtual addresses to physical addresses and checks permissions.
• A DMA-capable device does not automatically go through the CPU MMU.
• If the device is simply given a physical address, it may access memory directly.

• Therefore, ordinary CPU-side mechanisms such as:

  • page tables,
  • user/kernel privilege rings,
  • SMEP/SMAP-like CPU protections,

  cannot by themselves stop a malicious or buggy DMA device.

• A DMA-capable device may be able to read or write arbitrary physical memory if unrestricted.
• This means a malicious device could:
  • read secrets from RAM,
  • overwrite kernel data structures,
  • modify code or credentials,
  • bypass CPU privilege checks.
• This is especially dangerous for hot-plug devices.
• A hot-plug device can be attached while the system is already running.
• Historical attacks showed that plugging a malicious device into a running laptop could dump memory quickly.

• Storage is the part of the system responsible for long-term retention of data.
• The key property is persistence: data should survive after power loss, program termination, logout, and machine restart.

Persistence is not just a binary property. The lecture described a spectrum:

• Survive across program invocations.
• Survive across user logins.
• Survive across machine restarts.
• Survive across machine failures.
• Survive across disk failures.
• Survive across multiple disk failures.

• Main memory is not suitable for permanent storage because it loses data on power loss.
• Battery-backed memory can preserve data but is expensive, and the battery itself becomes a failure mode.
• Non-volatile memory provides memory-like persistence, but is a more specialized technology.
• Disks and flash storage are the main block storage technologies discussed.
• Tape is older but still relevant for large-scale archival storage.

The lecture placed storage in a stack:

• User level:
  • applications,
  • file interface.
• OS level:
  • file system,
  • block cache,
  • device drivers.
• Hardware level:
  • HDDs,
  • SSDs,
  • other persistent devices.

This lecture focused mostly on the hardware/block-device level. Later lectures move upward into caching, file systems, naming, reliability, and the POSIX/VFS interface.

• A block storage device exposes an array of blocks.
• Blocks can be read and written.
• A block is the minimum unit of access.
• You cannot read half a block or write only three bytes directly to the raw block device.
• Fine-grained byte operations are implemented by higher layers, usually by reading a whole block into memory, modifying bytes in memory, and writing the block back.

• Persistent across power loss.
• Large capacity.
• Low cost per byte compared to main memory.
• Random access support.
• Reliability: once data is written, later reads should return the same data unless a failure or corruption occurs.

An HDD contains:

• platters: spinning disks coated with magnetic material;
• spindle: motor-driven axis that rotates platters;
• surfaces: each platter side can store data;
• arm assembly: moves read/write heads over the platters;
• read/write head: reads and writes magnetic patterns.

Typical values discussed:

• physical size: about 1.8 to 3.5 inches;
• rotation speed: about 4,200 to 15,000 RPM;
• platters: often 1 to 8, giving 2 to 16 surfaces;
• tracks per surface: on the order of \(100K\);
• track width: tens to hundreds of nanometers;
• sectors per track: hundreds to thousands;
• sector size: today commonly 4 KiB;
• capacity: roughly 1 to 20+ TB;
• cost: relatively low per TB.

From the OS point of view, the disk exposes functions conceptually like:

ReadSector(logical_sector_number, buffer);
WriteSector(logical_sector_number, buffer);

• The OS uses a logical sector number.
• Historically, the logical sector number mapped more directly to physical geometry:
  • platter/head,
  • cylinder/track,
  • sector.
• Modern disks hide much of the physical layout behind logical block addressing and internal controllers.

To read a sector, the disk roughly performs:

1. Head selection: choose the correct surface/head.
2. Seek: move the arm to the correct cylinder.
3. Rotational latency: wait until the desired sector rotates under the head.
4. Transfer: read the sector into the disk buffer and then transfer it to main memory.

The access time is: \[ T_{\text{access}} = T_{\text{head selection}} + T_{\text{seek}} + T_{\text{rotation}} + T_{\text{transfer}}. \]

• Memory access is typically nanoseconds.
• HDD access is often milliseconds.
• That is a difference of many orders of magnitude.
• Seek time and rotational latency dominate.
• Therefore, operating systems and file systems must be designed to avoid unnecessary disk access.

• Disk access is slow.
• The OS should use a cache whenever possible.
• This motivates the buffer/page cache discussed in Lecture 13.

• Once the disk has paid seek and rotational cost for one sector, nearby sectors are cheap to read.
• Sequential access is therefore much faster than random access.
• The OS or device can use:
  • read-ahead,
  • prefetching,
  • sequential write aggregation.
• This only works when future accesses are predictable and sequential.

• Seeking is expensive.
• Disk scheduling reorders requests to reduce arm movement.
• Instead of serving requests strictly in arrival order, the OS or disk controller may choose an order with lower total seek distance.

• Related data should be placed near each other.
• For a file, blocks should ideally be on nearby sectors/tracks/cylinders.
• This allows sequential access and reduces both seeking and waiting.

• The OS had more explicit control over sectors.
• The OS performed more scheduling and placement decisions itself.
• The OS needed more knowledge of disk geometry.

• Logical Block Addressing made the disk look like a linear array of blocks.
• The disk controlled the physical layout.
• The OS still performed some request scheduling.

• Disk controllers accept multiple commands in parallel.
• Controllers internally reorder and schedule operations.
• Native Command Queuing (NCQ) is one example.
• The OS has gradually lost detailed control over physical placement and scheduling.

• Different disks have different internal layouts.
• Manufacturers implement hidden optimizations.
• Track buffering:
  • if the head is already passing over nearby sectors, the disk may read and cache them speculatively.
• Shingled Magnetic Recording (SMR):
  • tracks overlap like roof shingles to increase density;
  • writing one track may disturb adjacent tracks;
  • therefore, regions must often be written in order;
  • overwriting individual sectors becomes complicated.

• SSDs are not actually disks.
• They are built from NAND flash chips.
• They have no platters, heads, arms, or other moving parts.
• Nevertheless, SSDs are designed to look like disks:
  • physically, they may fit into disk-like form factors;
  • logically, they expose a sector/block interface to the OS.

• The basic read/write unit is a page, often 4 KiB.
• Pages are grouped into erase blocks.
• Example: one erase block may contain 64 pages.
• Each NAND chip contains many erase blocks.
• An SSD contains multiple NAND chips plus a controller and internal memory.

• The OS still sees functions like:

ReadSector(logical_sector_no, buffer);
WriteSector(logical_sector_no, buffer);

• The SSD internally maintains a logical sector map.
• The OS does not need to know which physical NAND page contains a logical sector.

• Higher bandwidth than HDDs.
• Much lower latency:
  • reads around \(10\mu s\),
  • writes around \(100\mu s\).
• Supports multiple outstanding commands.
• Random access is much less painful than on HDDs because there is no mechanical seek or rotation.

• Mobile consumer electronics.
• Laptops.
• High-end servers.
• Often combined with HDDs:
  • SSDs for hot data or caching,
  • HDDs for cheaper high-capacity storage.
• SSDs are also physically robust compared to HDDs because there are no moving parts.

The lecture used the classic idea:

• Many computer-science problems can be solved by adding another layer of indirection.
• For SSDs, the extra indirection layer is the Flash Translation Layer.

• The FTL maps logical page numbers to physical page numbers.
• It keeps a mapping table in SSD controller memory for fast lookup.
• It also stores mapping metadata persistently in flash, because the mapping must survive power loss.

1. Receive logical sector/page number.
2. Look up the physical page in the FTL table.
3. Read the physical page.

1. Receive logical sector/page number.
2. Allocate a new unused, already-erased physical page.
3. Write/program the new page.
4. Update the logical-to-physical mapping.
5. Mark the old physical page invalid/stale.
6. Erase invalid blocks later in the background.

• Writes can use pre-erased free pages.
• Expensive erases are moved off the critical write path.
• Garbage collection erases blocks in the background.

• The FTL tracks how much physical blocks have been erased.
• It tries to distribute writes and erases across blocks.
• This prevents a small set of hot logical pages from destroying the same physical blocks repeatedly.
• Wear leveling is the main mechanism that makes SSD lifetime acceptable.

• NVM means non-volatile memory.
• It allows byte-level access to persistent storage.
• Conceptually, it is closer to memory than to a block device.
• It is slower than DRAM but faster than conventional SSDs.
• It can blur the line between memory and storage.

• NVMe means Non-Volatile Memory Express.
• It is an interface/protocol for high-speed SSDs over PCIe.
• Despite the name, an NVMe SSD is still a block device.
• It is not byte-addressable memory.
• NVMe improves parallelism, bandwidth, and latency for SSD I/O.

• Disks improved much more slowly than CPUs.
• HDD latency and bandwidth improved by perhaps around one order of magnitude over decades.
• CPU performance improved by several orders of magnitude.
• This widened the storage/CPU gap.
• One way to improve storage bandwidth cheaply is to combine multiple disks.

• RAID originally means Redundant Array of Independent Disks.
• The key idea is parallel I/O across multiple drives.
• Benefits:
  • higher bandwidth,
  • larger logical capacity,
  • possible redundancy and reliability.

• Instead of placing all sectors on one disk, data is spread across disks.
• Example:
  • stripe 0 on disk 0,
  • stripe 1 on disk 1,
  • stripe 2 on disk 2,
  • and so on.
• Large reads and writes can access multiple disks in parallel.
• Idealized bandwidth with \(n\) disks:

\[ \text{bandwidth}_{RAID} \approx n \times \text{bandwidth}_{one\ disk}. \]

• In practice, the controller, I/O bus, workload, and implementation limit scaling.

• RAID can be implemented:
  • in a dedicated RAID box/controller with disks, memory, and processor;
  • in software by the OS kernel;
  • in hybrid forms with partial hardware support.
• A hardware RAID box may appear to the OS as one large disk.

• If data is striped across many disks and there is no redundancy, one disk failure can make the whole array unusable.
• With \(n\) disks, the array fails if any one disk fails.
• Approximate mean time between failures:

\[ MTBF_{array} \approx \frac{MTBF_{disk}}{n}. \]

• Example:
  • one disk MTBF \(\approx 50{,}000\) hours, about 5 years;
  • RAID with 10 disks has MTBF around 0.5 years.
• Therefore, plain striping improves performance but hurts reliability.

• Non-redundant disk array.
• Best read and write bandwidth among the covered schemes.
• Uses all disk capacity for data.
• Any disk failure causes data loss or unavailability.
• Good for performance when data loss is acceptable or data is replicated elsewhere.

• Every data disk has a mirror copy.
• Capacity is roughly half of raw disk capacity.
• Writes must go to both data and mirror disks.
• Reads can be served from either copy.
• After one disk fails, the surviving mirror can be used.
• Replacing a failed disk is conceptually simple: copy data from the surviving disk to the replacement.
• Tradeoff:
  • strong reliability and simple recovery;
  • expensive in capacity because every byte is stored twice.

• Uses \(N\) data disks plus one parity disk.
• For a stripe group, parity is computed by XOR:

\[ P = D_0 \oplus D_1 \oplus \cdots \oplus D_{N-1}. \]

• If one data disk fails, its data can be reconstructed:

\[ D_i = P \oplus D_0 \oplus \cdots \oplus D_{i-1} \oplus D_{i+1} \oplus \cdots \oplus D_{N-1}. \]

• If the parity disk fails, data disks still contain the data and parity can be rebuilt.
• Can tolerate one disk failure.
• More capacity-efficient than RAID-1.

• Similar to RAID-4, but parity is distributed across all disks.
• Different stripe groups place parity on different disks.
• This balances parity write load.
• Avoids the single dedicated parity-disk bottleneck.
• Can tolerate one disk failure.
• More complex than RAID-0 or RAID-1.

• HDDs are especially slow because of seek and rotational latency.
• SSDs are faster than HDDs but still much slower than DRAM.
• Therefore, repeatedly going to storage for the same data is wasteful.

• The CPU operates on memory addresses.
• To process file data, the OS must eventually bring it into memory.
• Once the data is already in memory, keeping it around can make future accesses much faster.

Applications and file systems often show locality:

• temporal locality:
  • recently used data is likely to be used again soon;
• spatial locality:
  • data near recently used data is likely to be used soon.

Caching exploits both.

• First read:
  • miss in cache;
  • fetch block from storage;
  • store it in memory.
• Later reads:
  • hit in cache;
  • avoid storage access;
  • return data from memory.

• Block devices operate at block granularity.
• Applications often write only a few bytes.
• Without a cache, a small write may require:
  1. read whole block,
  2. modify a few bytes in memory,
  3. write whole block back.
• With a cache, the OS can modify the cached block in memory and delay or combine writes.

• Multiple writes to the same block can be merged before writing back to disk.
• Sequential writes can be grouped into larger I/O requests.
• This improves performance and can reduce SSD wear.

• The buffer cache, also called the page cache, stores recently used storage blocks in memory.
• Persistent data remains on disk.
• Recently used data is also held in memory.
• The important design question is how to allocate and manage this memory.

• Simple approach:
  • allocate a fixed pool of buffers at boot;
  • use that pool only for disk block caching.

• In the fixed-cache design, the kernel may read a disk block into a separate buffer cache region, then copy it into a process buffer.
• In an integrated design, a physical page can simultaneously be:
  • the cached copy of a file block;
  • mapped into a process address space.
• Therefore, if a file block is already cached, the OS may only need to map the page rather than copy it.
• If a process writes to a shared page, the OS must handle correctness, for example through synchronization or copy-on-write depending on the mapping semantics.

Conceptual BSD-style functions:

// Fill buffer from underlying device/file.
int bread(struct vnode *vp, daddr_t blkno, int size, struct buf **bpp);

// Release a clean buffer.
void brelse(struct buf *bp);

// Synchronously write buffer contents to device/file.
int bwrite(struct buf *bp);

// Asynchronously write buffer contents.
void bawrite(struct buf *bp);

int bread_cluster(struct vnode *vp, daddr_t blkno, int size, struct buf **bpp);

• Reads the requested block.
• Also starts loading subsequent blocks.
• Useful when sequential access is likely.
• Hides future disk latency.

void bdwrite(struct buf *bp);

• Marks a buffer dirty.
• Queues it for later write-back.
• Allows the OS to:
  • combine writes;
  • schedule writes efficiently;
  • avoid immediate disk access.
• But delayed writes affect persistence semantics:
  • if the system crashes before write-back, dirty data may be lost;
  • applications that need durability must use explicit sync/fsync-like operations.

• Synchronous write:
  • caller waits until data is written.
  • stronger durability point.
  • slower.
• Asynchronous write:
  • write is queued or started in the background.
  • caller can continue sooner.
  • the OS must preserve correctness despite possible reordering or overlapping writes.

A buffer can be in one of the following conceptual states:

• Unused / Empty
• Clean
• Busy / Locked
• Dirty

• The buffer is free.
• It does not currently correspond to a useful disk block.
• It is available for new data.
• A read can allocate it and fill it from disk.

• The buffer contains data from disk.
• The memory copy is in sync with the disk copy.
• If the OS needs memory, a clean buffer can be reclaimed without writing it back.
• A clean buffer can be requested for I/O and become busy/locked.

• Some operation is currently using the buffer.
• The buffer may be read or modified.
• The kernel records this state so that other operations do not concurrently corrupt or reclaim the buffer.
• When the user/kernel operation releases the buffer:
  • if contents did not change, it returns to clean;
  • if contents changed, it becomes dirty.

• The buffer contains data that differs from the disk.
• It must eventually be written back to disk.
• After write-back completes, it becomes clean again.

• A real buffer cache implementation needs several data structures.
• It may organize buffers by:
  • state lists: locked, dirty, clean, empty;
  • hash table: key such as \((vnode, file offset)\) to quickly find cached blocks.
• The same buffer can be linked into multiple structures so the kernel can efficiently answer different questions:
  • Is block \(X\) of file \(Y\) cached?
  • Which dirty buffers need write-back?
  • Which clean buffers can be reclaimed?
  • Are there empty buffers available?

• A file system is a storage abstraction layer.
• It maps human/application-level file operations to block-device operations.
• It hides details such as:
  • block allocation,
  • placement,
  • free-space tracking,
  • metadata layout.

Without a file system, every application would need to manage:

• which disk blocks belong to it;
• how to grow or shrink data;
• how to avoid collisions with other applications;
• how to name and find stored data;
• how to enforce permissions;
• how to recover after crashes.

A file system centralizes these responsibilities.

• Naming:
  • human-readable names,
  • paths,
  • directories.
• Access permissions.
• Sharing:
  • between users,
  • between processes.
• Reliability.
• High performance.
• Persistence across runs, reboots, power outages, and failures.
• Concurrency support for simultaneous access.

• Disk management:
  • efficient use of disk space;
  • fast access to files and directories;
  • sharing space between users.
• Naming:
  • how users select and find files.
• Protection:
  • enforcing access permissions.
• Persistence:
  • surviving program runs, reboots, power outages, and hardware failures.
• Concurrency:
  • multiple processes/users may read and write simultaneously.

This lecture focused mainly on disk management: file structure and free-space management.

The file system must translate:

Read(uid, buffer, bytes);

into block-device operations such as:

ReadSector(logical_sector_number, buffer);

The central question:

• How do we use disk blocks to represent files?
• Storing bytes in blocks is easy.
• The hard part is knowing which block corresponds to which file and offset.

A file system must store information such as:

• file size;
• owner;
• access rights;
• access time;
• modification time;
• location of file blocks;
• free-space information.

• In Unix terminology, file metadata is stored in an inode.
• inode = index node.
• An inode contains:
  • file size,
  • permissions,
  • ownership,
  • timestamps,
  • pointers or indexes to the file’s data blocks.
• The important mapping is:

\[ (file,\ offset) \rightarrow block. \]

• The file system also needs to know which disk blocks are unused.
• This is needed when creating or growing files.
• Free-space metadata must also be persistent.
• If the system reboots and the free-space map was only in memory, the file system would not know which blocks are available.

A good file allocation scheme should:

• use disk space effectively;
• support fast sequential access;
• support random access when needed;
• avoid excessive fragmentation;
• allow files to grow;
• keep metadata compact;
• work well for both small and large files.

• Contiguous allocation / extents.
• Segmentation / multiple extents per file.
• Linked list of blocks.
• File Allocation Table (FAT).
• Indexed file.
• Multi-level indexed file.
• Dynamic extent trees.

• Allocate each file as one contiguous extent.
• An extent is:

\[ Extent(start, len) \] where start is the first block and len is the number of contiguous blocks.

• The inode only needs to record the start and length.
• The free-space map tracks unused extents.

• Very fast sequential access.
• Easy read-ahead.
• Compact metadata.
• Simple design.
• Good performance on HDDs because blocks are physically/logically close.

• A file may consist of multiple extents.
• The inode stores a table of \((base, size)\) pairs.
• Each pair describes a contiguous run of blocks.

• Still supports fast sequential access within each extent.
• More flexible than a single extent.
• A growing file can be extended by allocating another extent elsewhere.
• Reduces some external fragmentation compared with strict contiguous allocation.

• Still has some fragmentation.
• Metadata grows as the file becomes more fragmented.
• Sequential access across extent boundaries may require jumps.
• Too many small extents can degrade performance.
• Still has block-level internal fragmentation for tiny files.

• Organize the blocks of a file as a linked list.
• Each block stores a pointer to the next block.
• The file’s metadata stores at least the first block.
• Free space can be managed with a global free list.

• Constant-size per-file metadata, excluding the pointers stored in blocks.
• No external fragmentation:
  • any free block can be used.
• Easy to grow:
  • allocate a new block and link it at the end.

• FAT keeps the linked-list pointers in a separate table instead of inside each data block.
• Data blocks contain only file data.
• The FAT entry for a block tells which block comes next.
• File metadata or directory entries identify the first block of the file.

For a file whose first data block is 9:

• FAT[9] may point to 10.
• FAT[10] may point to 11.
• FAT[11] may point to 3.
• FAT[3] may point to the next block, and so on.
• An end marker indicates the end of the file.

• The pointer table is separate and can be cached in memory.
• Pointer chasing can happen in memory instead of on disk.
• This is much better than reading every data block just to find the next pointer.

• The FAT must be stored on disk for persistence.
• It is usually loaded/cached in memory.
• It needs entries for possible blocks.
• Therefore, metadata can be large.
• For FAT32-style entries, each entry is 32 bits.
• Maximum addressable size depends on entry size and block/cluster size.

• Conceptually simple.
• Data blocks are not polluted with next-block pointers.
• Better than raw linked lists if the FAT is cached.
• Supports finding the next block without reading the current data block.

• Large metadata table.
• Must cache the FAT for performance.
• Random access is still slow in the sense that the file system may need to walk the chain in the FAT.
• Fragmented files still cause non-sequential data I/O.
• Historically often required defragmentation for performance on HDDs.

• Keep an array of block pointers in the inode.
• Each pointer refers directly to a data block.
• Blocks are allocated dynamically as the file grows.

• Direct indexing is better for random access than linked lists.
• The file system can compute which pointer corresponds to a file offset.
• Data blocks do not need to store next pointers.

• The inode may need many pointers for large files.
• Lots of metadata may be stored in the inode.
• A maximum file size may need to be fixed at creation time.
• It is hard to predict how large a file will become.
• Wastes inode space for small files if too many pointer slots are reserved.

• Use an asymmetric tree of blocks rooted in the inode.
• The inode contains:
  • direct pointers to data blocks;
  • indirect pointer(s) to blocks that contain more pointers;
  • double-indirect pointer(s);
  • triple-indirect pointer(s).
• Indirect blocks are allocated only when needed.

• Point directly from inode to data blocks.
• Efficient for small files.
• Many small files can be represented without extra metadata blocks.

• Points to a block containing many data-block pointers.
• Allows larger files without putting all pointers directly in the inode.

• Points to a block of pointers to indirect blocks.
• Each indirect block then points to data blocks.
• Supports much larger files.

• Adds one more level.
• Supports very large files at the cost of more metadata lookups.

• The inode has a small number of direct pointers for small files.
• It also has indirect pointers for larger files.
• Small files stay cheap.
• Large files can still grow.

• Multi-level indexing allows holes.
• A file can have a large logical size without allocating blocks for all offsets.
• Example:
  • a 1 GiB file with data only at offset 0 and offset 1 GiB;
  • blocks in the middle need not be allocated.
• Reading a hole can return zeros without storing physical blocks.

• Unix Fast File System (FFS).
• ext2.
• ext3.

• Simple to manage compared with more complex dynamic extent trees.
• Metadata grows incrementally.
• Efficient for small files because direct pointers are enough.
• Supports sparse files.
• Allows files to grow after creation.

• Inefficient for very large files compared with extent-based schemes.
• Large files require many metadata blocks.
• Accessing blocks through double/triple indirection may require extra metadata reads.
• Metadata overhead can become large.

• Block-by-block pointer schemes are not ideal for large files.
• Large files often benefit from contiguous ranges.
• Extents are compact:
  • one extent can represent many contiguous blocks.
• Extents are fast:
  • sequential access works well if fragmentation is low.

• Organize extents in a dynamic tree.
• Inner nodes point to other tree nodes or extent descriptors.
• Leaves describe data extents.
• The tree height and shape can change as the file changes.
• This combines:
  • extent efficiency for large contiguous ranges;
  • dynamic growth like an index/tree structure.

• NTFS.
• ZFS.
• ext4.

• Low fragmentation when allocation succeeds well.
• Fast sequential access.
• Compact metadata for large contiguous files.
• Better for large files than block-by-block indexing.

• More complex implementation.
• Metadata overhead grows with fragmentation.
• Long-lived large files that are repeatedly modified can become fragmented.
• The file system needs more sophisticated allocation and tree maintenance.

• Free space exists, but not in large enough contiguous chunks.
• Affects contiguous and extent-based allocation.
• Makes it harder to allocate large contiguous files.

• Allocated space is not fully used.
• Example:
  • a 1-byte file still consumes at least one block.
• Also occurs if a file reserves an extent larger than its actual data.

• HDDs are very sensitive to fragmentation because fragmented files cause seeks.
• SSDs are less sensitive to physical seek costs, but fragmentation still affects:
  • metadata size,
  • I/O request count,
  • cache behavior,
  • write amplification in some cases.

• The file system must quickly find free blocks when creating or extending files.
• It must also free blocks when files shrink or are deleted.
• The method depends on the file organization scheme.

• Allocating a block should be fast.
• Allocating contiguous ranges should be possible when beneficial.
• Fragmentation should be minimized.
• Metadata overhead should remain acceptable.
• Free-space data must be persistent.

• Use one bit per disk block.
• Convention from the lecture:
  • bit = 1 means block is free;
  • bit = 0 means block is used.
• Allocation:
  1. find a bit set to 1;
  2. set it to 0;
  3. return the corresponding block number.
• Freeing:
  1. set the bit for that block back to 1.

For a 4 TB drive with 4 KiB blocks: \[ \frac{4\text{ TB}}{4\text{ KiB}} = \frac{2^{42}}{2^{12}} = 2^{30} \] blocks.

One bit per block means: \[ 2^{30}\text{ bits} = 2^{27}\text{ bytes} = 128\text{ MiB}. \]

So the bitmap overhead is about 128 MiB.

• Compact relative to disk size.
• Easy to test whether a block is free.
• Can be scanned for contiguous free ranges.
• Works well with bit-level and word-level operations.

• Large disks still require large bitmaps.
• Naive scanning can be slow.
• Finding large contiguous regions may require extra structure.
• The bitmap itself must be cached and updated consistently.

• Link all free blocks together.
• Each free block points to the next free block.
• Easy to implement.
• Easy to allocate one block at a time.
• Slow when trying to find multiple contiguous blocks.
• Poor for extent-based allocation.

• Similar to linked free list, but groups contiguous blocks together.
• Stores ranges rather than individual blocks.
• More efficient for allocating large runs.
• Better for large files and sequential layout.
• More complicated than a simple linked list.

• Contiguous allocation needs free extents.
• Linked-list file allocation can work with a simple free list.
• Extent trees benefit from free-space structures that find large contiguous regions.
• Multi-level indexed files can tolerate scattered blocks better, but still benefit from locality.