Part 2. Features of NTFS defragmentatoin
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.
To 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 ñompressed 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...
Means of the decision?
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:
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).
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.
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.
frånhttp://www.digit-life.com/articles/ntfs/
