Most disk drives are too large to draw their allocation with a pixel per cluster. Large disk drives are drawn by associating one or more cluster per pixel (cluster group). For example, if the disk contains a 350,000 clusters but the image drawn is (100 x 100 = 10,000 pixels), each pixel represents 35 clusters. The color of the pixel indicates the percent of the cluster group which is allocated. The color legend is drawn on the right edge of the image and starts with yellow (low percent allocated) to red (high percent allocated).
The color of the pixel does not indicate if the drive's files are fragmented. It just indicates how tightly packed the disk is allocated.
Blue and/or pink bars will be drawn marking the cluster sequences allocated by each file. The blue and pink color will alternate for each fragment of the file. Details of the allocation will appear in the small text list box on the right edge and a summary will appear in the status bar at the bottom. The blue and/or pink bars are drawn several pixels wide to make them easier to see.
A ring will be drawn on the beginning and ending cluster to make it easier to find. When a group of files are drawn, only the last file is marked.
If you hover over the filename in the right list table, it will redraw the files allocation and mark the beginning and ending allocation.
http://en.wikipedia.org/wiki/NTFS
NTFS contains several files which define and organize the file system. In all respects, most of these files are structured like any other user file ($Volume being the most peculiar), but are not of direct interest to file system clients. These metafiles define files, back up critical file system data, buffer file system changes, manage free space allocation, satisfy BIOS expectations, track bad allocation units, and store security and disk space usage information. All content is in an unnamed data stream, unless otherwise indicated.
Segment Number | File Name | Purpose |
---|---|---|
0 | $MFT | Describes all files on the volume, including file names, timestamps, stream names, and lists of cluster numbers where data streams reside, indexes, security identifiers, and file attributes like "read only", "compressed", "encrypted", etc. |
1 | $MFTMirr | Duplicate of the first vital entries of $MFT, usually 4 entries (4 KiB). |
2 | $LogFile | Contains transaction log of file system metadata changes. |
3 | $Volume | Contains information about the volume, namely the volume object identifier, volume label, file system version, and volume flags (mounted, chkdsk requested, requested $LogFile resize, mounted on NT 4, volume serial number updating, structure upgrade request). This data is not stored in a data stream, but in special MFT attributes: If present, a volume object ID is stored in an $OBJECT_ID record; the volume label is stored in a $VOLUME_NAME record, and the remaining volume data is in a $VOLUME_INFORMATION record. Note: volume serial number is stored in file $Boot (below). |
4 | $AttrDef | A table of MFT attributes which associates numeric identifiers with names. |
5 | . | Root directory. Directory data is stored in $INDEX_ROOT and $INDEX_ALLOCATION attributes both named $I30. |
6 | $Bitmap | An array of bit entries: each bit indicates whether its corresponding cluster is used (allocated) or free (available for allocation). |
7 | $Boot | Volume boot record. This file is always located at the first clusters on the volume. It contains bootstrap code (see NTLDR/BOOTMGR) and a BIOS parameter block including a volume serial number and cluster numbers of $MFT and $MFTMirr. $Boot is usually 8192 bytes long. |
8 | $BadClus | A file which contains all the clusters marked as having bad sectors. This file simplifies cluster management by the chkdsk utility, both as a place to put newly discovered bad sectors, and for identifying unreferenced clusters. This file contains two data streams, even on volumes with no bad sectors: an unnamed stream contains bad sectors—it is zero length for perfect volumes; the second stream is named $Bad and contains all clusters on the volume not in the first stream.[33] |
9 | $Secure | Access control list database which reduces overhead having many identical ACLs stored with each file, by uniquely storing these ACLs in this database only (contains two indices $SII: perhaps[citation needed] Security ID Index and $SDH: Security Descriptor Hash which index the stream named $SDS containing actual ACL table).[2] |
10 | $UpCase | A table of unicode uppercase characters for ensuring case insensitivity in Win32 and DOS namespaces. |
11 | $Extend | A filesystem directory containing various optional extensions, such as $Quota, $ObjId, $Reparse or $UsnJrnl. |
12 ... 23 | Reserved for $MFT extension entries.[34] | |
usually 24 | $Extend\$Quota | Holds disk quota information. Contains two index roots, named $O and $Q. |
usually 25 | $Extend\$ObjId | Holds distributed link tracking information. Contains an index root and allocation named $O. |
usually 26 | $Extend\$Reparse | Holds reparse point data (such as symbolic links). Contains an index root and allocation named $R. |
These metafiles are treated specially by Windows and are difficult to directly view: special purpose-built tools are needed.[35]
For each file (or directory) described in the MFT record, there's a linear repository of stream descriptors (also named attributes), packed together in a variable-length record (also named an attributes list), with extra padding to fill the fixed 1KB size of every MFT record, and that fully describes the effective streams associated with that file.
Each stream (or attribute) itself has a single type (internally just a fixed-size integer in the stored descriptor, but most often handled in applications using an equivalent symbolic name in the FileOpen() or FileCreate() API call), a single optional stream name (completely unrelated to the effective filenames), plus optional associated data for that stream. For NTFS, the standard data of files, or the index data for directories are handled the same way as other data for alternate data streams, or for standard attributes. They are just one of the attributes stored in one or several attribute lists.