This article was previously published under Q228198
This article has been archived. It is offered "as is" and will no longer be updated.
A Disk Defragmenter analysis on a volume that uses the NTFS file system may report some files with a large number of fragments even though the file sizes are small.For example, you may see an Analysis Report similar to:
Fragments File Size Files that did not defragment -------------------------------------------------------------------- 14 1 KB \WINNT\system32\config\software.LOG 8 1 KB \WINNT\system32\config\default.LOG 11 1 KB \Documents and Settings\joeuser\ntuser.dat.LOG
Files are allocated in multiples of the NTFS cluster size. The default cluster size can range from 512 to 4,096 bytes, depending on the volume size when it is formatted. The minimum file allocation is one cluster. When a file is open for write access, NTFS attempts to preallocate additional space to help prevent fragmentation as the file grows.
In Windows Explorer, the file properties may appear as:
Size: 1.00KB (1,024 bytes) Size on Disk: 4.00KB (4,096 bytes)
Within the NTFS file system, the file is preallocated additional space in separate extents that the Disk Defragmenter report shows. The "Size on Disk" value reports the size that you would obtain if you were to close the file. Because there is no data written to these extra allocations, it is not reported by Windows Explorer. When the file is eventually closed, the allocation is rounded down and the additional extents are released. However, even after a full volume defragmentation, the file may again appear as being fragmented after it is opened for write access again.
When you defragment a volume, the current defragmentation APIs do not allow the extra space to be moved and consolidated while the file is open. When you reboot the computer, or the file is closed, the extra reserved space is freed. The next time the file is opened for write access, NTFS checks for nearby clusters with the current end of file (EOF) and allocates additional free clusters starting there.
NOTE: It is sometimes better for a file to be noncontiguous "nearby" than contiguous "far away" because there is no performance penalty for performing input/output (I/O) operations within the same cylinder. If you have to move the disk's physical heads to fetch pieces of the file, you pay a performance price.
For additional information about Windows 2000 Disk Defragmenter, click the article numbers below to view the articles in the Microsoft Knowledge Base: