Fragmentation report in JKD 4

[poutnik]

What about, at least in analysis only mode, include percentual fragmentation report ?
And, possibly, based on it, conditional running of  defragment a/o fast optimize mode ?

I know what you have told more times about -a 3 daily usability. 
But even that, it often causes very significant disk activity on my system partition.
Even if run twice a day, without big prior changes, caused by user ( me ).

In time of Windows 95/98, I often used utility called CrackUp by PCMAG. I suppose it is not usable for NTFS, but its formula lasts.....     CrackUp Alerts You to Disk Fragmentation - Computing Fragmentation

Essential quote:

CrackUp also considers free space when calculating fragmentation. Contiguous regions of free space can occur at the physical ends of the disk (unbounded free space) or between allocated fragments (bounded free space). Bounded free space is, by definition, fragmented. Since we're concerned only with the portion of the disk that's actually being used to store files (that is, the space from the first to the last allocated cluster, inclusive), we exclude unbounded free space from our calculations. If we did not, the reported fragmentation level would be artificially low, especially if the disk were not very full.

Percentage of fragmentation for all files is calculated as follows:

((extra fragments + bounded free fragments)/(total clusters - unbounded free clusters)) * 100

There is one last factor: Windows' Defrag considers certain files to be unmovable. This includes any files with both the hidden and system attributes set, along with the system swap file. Since Defrag won't defragment these files, you may wish to exclude them from the overall calculation. The percentage of fragmentation for movable files only is calculated this way:

((movable extra fragments + bounded free fragments)/(total clusters - unbounded free clusters - unmovable clusters)) * 100

[jeroen]

Thank you very much for your contribution, I appreciate it! At the moment I am working on v4 of JkDefrag, which will have several methods to conditionally process all the disks, a single disk, a single zone, or even a single file. Something like your formula will be there, and some others. Your formula is good for fragmentation, but ignores optimization, which is far more important.

[poutnik]

I agree.

Formula for optimization would be far more complex 

If partition is lets say first 1/10 of disk, optimization partly loses its importance.
Speed difference of start vs end tracks is in my case about 3%.

BTW it could be time lost in short Version 4 feature list writing
could quickly turn into time gain, couldnt it ?

[poutnik]

But fragmentation index is IMHO good indirect index of optimization.

Like microbiological screening of water supplies. There are often detected almost harmless species, easy to detect, as indirect indicator of possible presence of harmful species, that are difficult to detect.

[jeroen]

Like microbiological screening of water supplies.

Nice analogy! Yes, a high number of fragments and gaps does indeed indicate a need for optimization. But a low number does not necessarily mean good optimization. The formula does not take into account the location of the files. For example, if all the files are located at the slow end of the disk, then the formula will produce the exact same number as when all the files are at the fast end of the disk.

If partition is lets say first 1/10 of disk, optimization partly loses its importance.

Partly, yes, but not entirely. The main benefit of optimization comes from placing files as close together as possible, reducing access times. Placing files at the fastest part of the disk is also important, increasing bandwidth, but less so. This is why the spacehogs in JkDefrag are so successful, it allows for small files to be placed closer together, reducing access times.

[poutnik]

.......if all the files are located at the slow end of the disk, then the formula will produce the exact same number as when all the files are at the fast end of the disk.

This hardly happens if JKD is used. General file placement is already done.

The main benefit of optimization comes from placing files as close together as possible, reducing access times.

I in general agree about importance: Relative location > Location > Fragmentation.

Vista Defrag in default and one of JKD mode do not defragment fragments >cca 64MB ( latter only optimize them), access time being cca 1% of fragment transfer time. 

On the other hand - getting small, frequently modified files fragmented - relative placement of its future fragments is more important than current optimized location.

[poutnik]

The main benefit of optimization comes from placing files as close together as possible, reducing access times.

Hmm, considering that,

all files and folders in NTFS has 1st fragment contained inside MFT and if small enough, there have no clusters outside MFT.

Speaking about MFT placement some time ago ( MS recommends place it at 1/3 of partiton ),
you had said MFT is highly cached and therefore MFT position has only minor impact.
These folder fragments are several times smaller then MFT ( cca 1/4 of MFT at partitions I was checking ) and folders are cached too, since Windows 9x at least.

Placement these folder fragments in start of disk is therefore questionable.

[jeroen]

Placement these folder fragments in start of disk is therefore questionable.

I am sorry, but I do not follow. Both the MFT and the folders should ideally be placed at the center of activity of the harddisk. JkDefrag does not do that (yet), it cannot move the MFT at all and always places folders at the beginning of the disk. I am working on a new version of JkDefrag that will make it possible to move the MFT (on Vista) and the directories to wherever the user wants to put them. Does that answer your question?

[poutnik]

I am sorry, but I do not follow. Both the MFT and the folders should ideally be placed at the center of activity of the harddisk. JkDefrag does not do that (yet), it cannot move the MFT at all and always places folders at the beginning of the disk. I am working on a new version of JkDefrag that will make it possible to move the MFT (on Vista) and the directories to wherever the user wants to put them. Does that answer your question?

In fact it was not question, but a note or comment.  :-)
I am sorry if I have confused you. Do not worry, you DO follow.
We both think similar here and JKD4 goes this way.