How file systems store data: clusters, allocation, slack and unallocated space

A file system turns a volume's raw sectors into named files. It stores content in fixed-size units, records which units are in use and keeps metadata and names in separate structures, each of which can survive or be erased on its own. Understanding this lets an examiner explain why a deleted file is recoverable, where an old fragment came from and what that fragment can and cannot prove. Later lessons apply this model to NTFS, FAT, ext4 and APFS.

A reasoning framework: Carrier's five categories

Brian Carrier (File System Forensic Analysis, 2005) sorts file system data into five categories. The model applies to every file system and makes you ask which category a piece of evidence belongs to.

The categories fail separately. A name can survive after its metadata entry was reused, a metadata entry can point to clusters that now belong to another file, and content can survive with no name or metadata. Many reporting errors come from treating evidence in one category as proof of something in another.

Clusters, blocks and allocation units

A disk is addressed in sectors, usually 512 bytes (some drives use 4,096-byte sectors; "512e" drives present 512-byte logical sectors over 4,096-byte physical ones). A file system groups a fixed number of consecutive sectors into a cluster (FAT, exFAT and NTFS), a block (ext4) or, generically, an allocation unit. The size is set at format time and recorded in the file system category. On NTFS the boot sector stores bytes per sector at offset 0x0B and sectors per cluster at offset 0x0D. NTFS volumes commonly use 4,096-byte clusters, and ext4 commonly uses 4,096-byte blocks.

The cluster is the smallest unit a file system can give to a file, because the allocation structures track one status per cluster; tracking each sector or byte would make them far larger and slower. A file therefore occupies a whole number of clusters, even when it is one byte long. Its logical size is the number of bytes the file holds. Its physical (allocated) size is the number of clusters × cluster size. The difference is file slack.

NTFS has one exception. A very small file can be stored resident, inside its MFT record, and then it uses no clusters at all. Lesson 1.3 covers resident data.

Allocation structures

Each file system records which clusters are in use:

• NTFS uses $Bitmap (MFT record 6), which holds one bit per cluster (1 = allocated). The use of MFT records is tracked separately, in the $BITMAP attribute of $MFT, and in the in-use flag (0x0001) in each record header.
• FAT12/16/32 use the File Allocation Table, which has one entry per cluster. 0 means free; other values give the next cluster in the chain, end of chain or a bad cluster. FAT32 entries are 32 bits wide, and the low 28 bits are used. On FAT, the table is both the allocation map and the record of where each file's content is stored.
• exFAT uses an allocation bitmap, and it uses the FAT mainly for files that are fragmented.
• ext4 uses block bitmaps and inode bitmaps for each block group.

What "deleting" a file usually does

On most file systems, deleting a file changes allocation status. It does not erase content. Typical results:

• NTFS: the in-use flag in the MFT record is cleared, the file's bits in $Bitmap are set to 0 and the entry is removed from the parent directory's index. The record usually keeps its attributes, timestamps and data runs until reused.
• FAT: the first byte of the directory entry is set to 0xE5 and the file's chain in the FAT is set to 0 (free). The directory entry usually still records the size and the starting cluster (on FAT32 some implementations clear its upper 16 bits), but the chain linking the remaining clusters is gone.
• ext3/ext4: the inode and its blocks are marked free. The block-location information in the inode is commonly cleared as well, which makes recovery from metadata harder.

In each case the content stays in the clusters until it is overwritten. On solid-state drives, TRIM can make released blocks read back as zeros even though nothing new was written. Lesson 1.8 compares recovery from metadata with file carving.

Fragmentation

A file is fragmented when its clusters are not contiguous; NTFS records the pieces as data runs and FAT as links in the cluster chain. With intact metadata this does not matter, because every run is listed. Without metadata it does: a carving tool that assumes contiguity will join unrelated clusters to the first fragment.

File slack: RAM slack and drive slack

File slack (also called cluster slack) is the space from the end of a file's logical size to the end of its last cluster. It has two parts:

• RAM slack runs from the end of the file data to the end of the sector that contains it. The disk writes whole sectors, so the operating system must supply bytes to fill it. The name comes from older systems, such as MS-DOS and early Windows on FAT, which filled it with whatever was in the memory buffer. Current Windows versions write zeros there, so on an NTFS volume written by a modern Windows system you should expect RAM slack to be zero-filled. If you find non-zero RAM slack, explain it (an older OS, another driver or tool, or a file system other than NTFS) rather than assuming it.
• Drive slack, also called residual slack, is the whole sectors in the last cluster after the sector that holds the end of the file. They are not written, so they keep whatever was there before, often a remnant of an earlier, deleted file.

If a file later shrinks, its own earlier content beyond the new end becomes slack.

Worked example

A file has a logical size of 10,000 bytes. It is on a volume with 4,096-byte clusters and 512-byte sectors (8 sectors per cluster).

1. Clusters needed: 10,000 ÷ 4,096 = 2.44, rounded up to 3 clusters.
2. Allocated size: 3 × 4,096 = 12,288 bytes.
3. File slack: 12,288 − 10,000 = 2,288 bytes.
4. Data in the last cluster: 10,000 − (2 × 4,096) = 10,000 − 8,192 = 1,808 bytes.
5. Sectors used in that cluster: 1,808 ÷ 512 = 3 remainder 272. That is three full sectors, plus 272 bytes in the fourth sector.
6. RAM slack: 512 − 272 = 240 bytes, at offsets 1,808–2,047 within the cluster.
7. Drive slack: 8 − 4 = 4 whole sectors, so 4 × 512 = 2,048 bytes, at offsets 2,048–4,095.
8. Check: 240 + 2,048 = 2,288, which matches step 3.

To locate these regions in the image, assume an NTFS volume (cluster 0 begins at the volume's first sector) starting at sector 2,048, with the last cluster at cluster 120,000:

Volume slack and partition gaps

Data can also lie outside every file system.

• Volume slack is the space between the end of the file system and the end of the volume that contains it. It occurs when the volume size is not an exact multiple of the cluster size, or when the file system was created smaller than its partition or the partition was later enlarged.
• Partition gaps are sectors that no partition covers. Examples are the sectors between the partition table and the first partition (sectors 1–2,047 on an MBR disk whose first partition starts at sector 2,048), space between two partitions and space after the last partition.

These areas usually hold zeros or leftovers from earlier partitioning; non-zero data there deserves explanation, because hiding tools use them. Lesson 1.1 shows how to locate them.

Unallocated space versus free space

Unallocated space is the set of clusters that the allocation structure marks as not in use. It is a status, not a description of content. Free space is the capacity the operating system reports as available. It is derived from the same status but says nothing about content: "20 GB free" may be 20 GB of recoverable deleted data. In a report, say "unallocated," never "empty." Unpartitioned space is different again, because it lies outside every file system.

What each area can and cannot prove

Slack and unallocated content has no file system metadata. Any date or author must come from the content itself, such as a document's internal metadata or a timestamp in a log line, and must be corroborated.

How tools expose these areas

The Sleuth Kit has commands for each category. fls -d lists deleted file names (add -r to recurse, -p for full paths and -o for the partition's sector offset). istat shows a metadata entry. blkstat shows whether a cluster is allocated. ifind -d finds the metadata entry that points to a given cluster. blkls extracts unallocated data units by default (-A). With -s it extracts slack, and with -e it extracts every unit. When a keyword hit is found in blkls output, blkcalc -u <unit> converts the unit number back to the cluster address in the original volume. Autopsy shows the same areas as deleted-file views, virtual "Unalloc" files and per-file -slack files.

Exam focus: Expect to calculate allocated size, file slack, RAM slack and drive slack from a file size, cluster size and sector size, and to convert a cluster number into a byte offset. Questions may also ask what deletion changes on a given file system and what slack or unallocated content can establish about time and authorship.

Key points

• Carrier's five categories (file system, content, metadata, file name, application) can survive or be lost separately, so name the category of every piece of evidence.
• The cluster is the smallest allocation unit. A file's allocated size is its cluster count × cluster size, and the difference from its logical size is file slack.
• Deletion normally changes allocation status and metadata, and the content stays until it is overwritten or, on SSDs, possibly TRIMmed.
• RAM slack on modern Windows/NTFS is normally zero-filled. Drive slack consists of unwritten sectors that can hold an earlier file's remnants.
• Unallocated space is a status, not emptiness. Content found there or in slack cannot be dated or attributed without independent evidence.