Editing NTFS (section)

=== Resident vs. non-resident attributes ===
To optimize the storage and reduce the I/O overhead for the very common case of attributes with very small associated value, NTFS prefers to place the value within the attribute itself (if the size of the attribute does not then exceed the maximum size of an MFT record), instead of using the MFT record space to list clusters containing the data; in that case, the attribute will not store the data directly but will just store an allocation map (in the form of ''data runs'') pointing to the actual data stored elsewhere on the volume.<ref>{{cite web|url=http://blogs.technet.com/b/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx|title=The Four Stages of NTFS File Growth|access-date=22 September 2018|archive-url=https://web.archive.org/web/20180923052803/https://blogs.technet.microsoft.com/askcore/2009/10/16/the-four-stages-of-ntfs-file-growth/|archive-date=23 September 2018|url-status=dead}}</ref> When the value can be accessed directly from within the attribute, it is called "resident data" (by [[computer forensics]] workers). The amount of data that fits is highly dependent on the file's characteristics, but 700 to 800 bytes is common in single-stream files with non-lengthy filenames and no ACLs.
* Some attributes (such as the preferred filename, the basic file attributes) cannot be made non-resident. For non-resident attributes, their allocation map must fit within MFT records.
* Encrypted-by-NTFS, sparse data streams, or compressed data streams cannot be made resident.
* The format of the allocation map for non-resident attributes depends on its capability of supporting sparse data storage. In the current implementation of NTFS, once a non-resident data stream has been marked and converted as sparse, it cannot be changed back to non-sparse data, so it cannot become resident again, unless this data is fully truncated, discarding the sparse allocation map completely.
* When a non-resident attribute is so fragmented that its effective allocation map cannot fit entirely within one MFT record, NTFS stores the attribute in multiple records. The first one among them is called the base record, while the others are called extension records. NTFS creates a special attribute {{mono|$ATTRIBUTE_LIST}} to store information mapping different parts of the long attribute to the MFT records, which means the allocation map may be split into multiple records. The {{mono|$ATTRIBUTE_LIST}} itself can also be non-resident, but its own allocation map must fit within one MFT record.
* When there are too many attributes for a file (including ADS's, extended attributes, or [[security descriptor]]s), so that they cannot fit all within the MFT record, extension records may also be used to store the other attributes, using the same format as the one used in the base MFT record, but without the space constraints of one MFT record.

The allocation map is stored in a form of ''data runs'' with compressed encoding. Each data run represents a contiguous group of clusters that store the attribute value. For files on a multi-GB volume, each entry can be encoded as 5 to 7 bytes, which means a {{val|1|ul=KB}} MFT record can store about 100 such data runs. However, as the {{mono|$ATTRIBUTE_LIST}} also has a size limit, it is dangerous to have more than 1 million fragments of a single file on an NTFS volume, which also implies that it is in general not a good idea to use NTFS compression on a file larger than {{val|10|ul=GB}}.<ref>{{cite web |url=https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |title=A heavily fragmented file in an NTFS volume may not grow beyond a certain size |access-date=2021-05-19 |url-status=live |archive-url=https://web.archive.org/web/20210506185845/https://support.microsoft.com/en-us/topic/a-heavily-fragmented-file-in-an-ntfs-volume-may-not-grow-beyond-a-certain-size-da1c0dfd-a5a1-90b4-4bf7-b65b13ef9d35 |archive-date=2021-05-06}}</ref>

The NTFS file system driver will sometimes attempt to relocate the data of some of the attributes that can be made non-resident into the clusters, and will also attempt to relocate the data stored in clusters back to the attribute inside the MFT record, based on priority and preferred ordering rules, and size constraints.

Since resident files do not directly occupy clusters ("allocation units"), it is possible for an NTFS volume to contain more files on a volume than there are clusters. For example, a {{val|74.5|u=GB}} partition NTFS formats with 19,543,064 clusters of {{val|4|u=KB}}. Subtracting system files (a {{val|64|ul=MB}} log file, a 2,442,888-byte Bitmap file, and about 25 clusters of fixed overhead) leaves 19,526,158 clusters free for files and indices. Since there are four MFT records per cluster, this volume theoretically could hold almost 4 × 19,526,158 = 78,104,632 resident files.