iXBT Labs - Computer Hardware in Detail






NTFS File System

<< Previous page

     Next page >>

NTFS defragmentation features

Let's return to one interesting enough and important moment -- NTFS fragmentation and defragmentation. The situation with these two concepts at the moment can not be called satisfactory in any way. At the very beginning it was said that NTFS is not subject to file fragmentation. It is not exactly so and the statement was changed -- NTFS prevents fragmentation. It is not exactly so either. That is it certainly prevents but, it is already clear that NTFS is a system which is predisposed to fragmentation inspite of official statements. But it doesn't suffer from it. All internal structures are constructed in such way that fragmentation does not hinder to find data fragments fast. But it doesn't save from the physical effect of fragmentation -- waste disk heads motions.

The source of the problem

As it is known, the system fragments files the best way when the free space is being ended, when it is necessary to use small-sized unused space remained from other files. The first NTFS property which directly promotes serious fragmentation appears here.

NTFS disk is divided into two areas. In beginning of the disk there is MFT area -- the area where MFT grows (Master File Table). The area occupies minimum 12% of the disk, and the data record in this area is impossible. It is made not to let MFT be fragmented. But when all remaining disk is being filled in -- the area is reduced twice. And so on. Thus we have not single pass of the disk ending, but several. In result if NTFS works at the disk filled on about 90% -- fragmentation grows greatly.

The incidental result -- the disk filled more than on 88% is almost impossible to be defragmented -- even defragmentation API cannot transfer the data in MFT area. It is possible that we will not have free space for a manoeuvre.

NTFS works and works and is fragmented -- even in the case of free space is far from exhausting. This is promoted by the strange algorithm of finding free space for file storage -- second serious omission. The action algorithm at any record is like this: some definite disk range is taken and filled in with a file. It is done by the very interesting algorithm: at first large unused space is filled in and then small one. I.e. the typical allocation of file fragments according to the size on fragmented NTFS looks so (sizes of fragments):

16 -- 16 -- 16 -- 16 -- 16 -- [back] -- 15 -- 15 -- 15 -- [back] -- 14 -- 14 -- 14.... 1 -- 1 -- 1 -1 -- 1...

So the process goes up to most small-sized unused space in 1 cluster, in spite of the fact that on the disk there are also much larger pieces of free space.

Recall compressed files -- at active overwriting of the large volumes compressed information on NTFS the huge quantity of "holes" are because of reallocation compressed cluster groups on the disk. If any file area began to be compressed better or worse, it is necessary either to take it from a continuous chain and to place in another place or to strap in size reserving unused space.

It is impossible to say that NTFS prevents file fragmentation. On the contrary it fragments them with pleasure. NTFS fragmentation can surprise any person familiar with file system operation in half a year of work. Therefore it is necessary to launch defragmentation. But here all our problems are not ended, they only start.


In NT there is standard API defragmentation. It has the interesting limit for files block relocating: it is possible to transfer not less than 16 clusters (!) at once, and these clusters should start from the position16 clusters aligned in a file. In common, the operation is carried out extremely for 16 clusters. The results:

  1. It is impossible to transfer anything in the unused space less than 16 clusters (except compressed files but it is not interesting at the moment).
  2. A file being transferred in another place leaves (in the new place) "the temporarily occupied space" adding it on the size up to multiplicity to 16 clusters.
  3. At attempt to transfer a file the wrong way ("not multiply to 16 ") the result is often unpredictable. Something is just not transferred, but the whole arena is gracefully littered wit "the temporary occupied space". These "the temporarily occupied space" serves for simplification of system restoration in the case of a machine failure and is usually freed half a minute later.

Nevertheless it would be logical to use this API if it is in stock. And it is used. Therefore the standard defragmentation process with the corrections on limitation API consists of the following phases (not necessarily in this order):

  • Files extraction from MFT area. Not specially -- just because it is impossible to put them back. This phase is harmless and even somehow useful.
  • Files defragmentation. Unconditionally it is a useful process but a bit complicated by limitings of relocatings multiplicity -- we have to move files more that it would be otherwise necessary.
  • MFT, pagefile.sys and directories defragmentation. It is possible through API only in Windows2000, in the opposite case -- at reboot, as a separate process like in old Diskeeper.
  • The addition of files is closer to the beginning -- so-called free space defragmentation. It is a terrible process.

If we want to put files on end in the beginning of the disk, we shall put one file. It leaves unused space from its end up to the block (16 clusters) boundary for alignment. Then we put the following, and after that we have the unused space of size less than 16 clusters. Then it is impossible to fill in it through API defragmentation! In result before optimisation the overview of free space looked like this: there were a lot of unused space of the same size. After optimisation -- one "hole" at the end of the disk, and a lot of small < 16 clusters ones in the section filled by files. What places are first to be filled in? mall-sized "holes" < 16 clusters taking place closer to the beginning of the disk. Any file slowly built on optimised disk will consist of great number of fragments. Then the disk can be optimised again. And then once again.

Thus there are two about equivalent options. The first one is to optimise the disk often by such defragmentator paying no attention to such great fragmentation of the newly created files. The second variant is not to change anything and put up with regular but much weaker fragmentation of all disk files.

While there is only one defragmentator which ignores API defragmentation and works more directly -- Norton Speeddisk 5.0 for NT. When it is compared to all remaining -- Diskeeper, O&O defrag, etc. -- the main difference is not mentioned. It is just because this problem is carefully hidden. Speeddisk is the unique for today program which can optimise the disk completely not establishing small fragments of free space.

Unfortunately the defragmentator working through API which makes unused space <16 clusters was placed in Windows 2000.

All remaining defragmentators are just harmful at one-time application. If you launched it even one time, you would need to launch it then at least once a month to be saved from new files fragmentation. This is the problem of NTFS defragmentation by old means.

What to choose?

Any of the represented nowadays file systems is rather old and NTFS is a very old system! PC for a long time used only operating system DOS and FAT is owed it by its appearance. But some systems aimed to the future were developed and existed then. Two such systems obtained the wide recognition -- NTFS created for the operating system Windows NT 3.1 and HPFS -- a true friend of OS/2.

The implantation of new systems was difficult. In 1995 at appearance Windows95 nobody thought that something needed to be changed. FAT32 appeared in Windows 95 OSR2 didn't change the essence of the system which just does not give the possibility to organise effective operation with a plenty of data but widen the boarders.

HPFS (High Performance File System) actively used till nowadays by OS/2 users has shown itself as enough successful system, but also it had essential disadvantages -- complete absence of automatic restorability means, excessive complexity of data structure and the low-level of flexibility.

NTFS could not win personal computers for a long time because of the fact that for organisation of effective operation with the data structures it demanded significant memory sizes. The systems with 4 or 8 MByte (standard of 1995-1996) were just unable to get though any plus from NTFS. Therefore it had incorrect reputation of a slow and bulky system. Actually it does not fit the reality -- modern computer systems with memory more than 64 Mbytes get just huge increase of productivity from NTFS usage.

In the given table all essential pluses and minuses of the widespread presently systems such as FAT32, FAT and NTFS are shown together. It is hardly reasonable to discuss other systems, as now 97% of the users make choice between Windows98, Windows NT4.0 and Windows 2000 (NT5.0), and other variants are just not present.

Systems DOS, Windows9x, all NTs Windows98, NT5 NT4, NT5
Max. volume size 2 GBytes Almost unlimited Almost unlimited
Max. file count Around 65000 Almost unlimited Almost unlimited
File names Long names (up to 255 chars), system character set Long names (up to 255 chars), system character set Long names (up to 255 chars), Unicode character set
File attributes Basic set Basic set Up to software developers
Security No No Yes (physical encryption capability from NT5 on)
Compression No No Yes
Fault tolerance Middle Low Full (automatic)
Economy Min. Improved (small clusters) Max.
Performance High for small files count Similar to that of FAT, with an additional penalty for big volumes Very effective for all volumes

It would be desirable to tell that if your operating system is NT (Windows 2000), then to use any file system which differs from NTFS means to limit the convenience and flexibility of operating system operation. NT and especially Windows 2000 with NTFS are two parts of a unit. A lot of useful NT possibilities are directly connected with physical and logical structure of the file system, and you should use FAT or FAT32 there only for compatibility -- if you have the task to read these disks from any other systems.

Write a comment below. No registration needed!

<< Previous page

Article navigation:

Page 1: Introduction, physical structure

Page 2: Physical structure cont'd

Page 3: Defragmentation features, what to choose

blog comments powered by Disqus

  Most Popular Reviews More    RSS  

AMD Phenom II X4 955, Phenom II X4 960T, Phenom II X6 1075T, and Intel Pentium G2120, Core i3-3220, Core i5-3330 Processors

Comparing old, cheap solutions from AMD with new, budget offerings from Intel.
February 1, 2013 · Processor Roundups

Inno3D GeForce GTX 670 iChill, Inno3D GeForce GTX 660 Ti Graphics Cards

A couple of mid-range adapters with original cooling systems.
January 30, 2013 · Video cards: NVIDIA GPUs

Creative Sound Blaster X-Fi Surround 5.1

An external X-Fi solution in tests.
September 9, 2008 · Sound Cards

AMD FX-8350 Processor

The first worthwhile Piledriver CPU.
September 11, 2012 · Processors: AMD

Consumed Power, Energy Consumption: Ivy Bridge vs. Sandy Bridge

Trying out the new method.
September 18, 2012 · Processors: Intel
  Latest Reviews More    RSS  

i3DSpeed, September 2013

Retested all graphics cards with the new drivers.
Oct 18, 2013 · 3Digests

i3DSpeed, August 2013

Added new benchmarks: BioShock Infinite and Metro: Last Light.
Sep 06, 2013 · 3Digests

i3DSpeed, July 2013

Added the test results of NVIDIA GeForce GTX 760 and AMD Radeon HD 7730.
Aug 05, 2013 · 3Digests

Gainward GeForce GTX 650 Ti BOOST 2GB Golden Sample Graphics Card

An excellent hybrid of GeForce GTX 650 Ti and GeForce GTX 660.
Jun 24, 2013 · Video cards: NVIDIA GPUs

i3DSpeed, May 2013

Added the test results of NVIDIA GeForce GTX 770/780.
Jun 03, 2013 · 3Digests
  Latest News More    RSS  

Platform  ·  Video  ·  Multimedia  ·  Mobile  ·  Other  ||  About us & Privacy policy  ·  Twitter  ·  Facebook

Copyright © Byrds Research & Publishing, Ltd., 1997–2011. All rights reserved.