Analysis display enhancement request & "Density"

[tOM Trottier]

Jeroen,

Your current analysis display for big or fragmented files shows:
  Fragments       Bytes  Clusters Name
          1  2097152000    512000 C:\pagefile.sys
          1  1063440384    259629 C:\hiberfil.sys
...

I think it would be more useful if you
 - showed MB rather than bytes - easier to read
 - used % of disk instead of clusters - who cares much about cluster details?
 - didn't bother with the number of clusters
 - showed where the first cluster is
 - showed "density" of the file - what % of the space between the first and last cluster (diskwise) of the file is the file. EG, single fragment files would always be 100%

e.g.
Fragments    Bytes    First   Density  Name
        1  2,048.0MB   40%    100.0%   C:\pagefile.sys
        4    703.0MB   83%     41.8%   C:\Installs\ubuntu-7.10-desktop-i386.iso
       14      0.3MB   13%      0.1%   C:\Documents and Settings\Tom\My Documents\gardening.7z
...

eg, The 41.8% would indicate that between the first and last cluster positions on disk of the ubuntu file, 41.8% of the space is taken up by ubuntu file.


"Density" would also be a useful measure of goodness for fragmented files. Efforts to increase the density of fragmented files would speed access, eg, if you find a file currently extends across 45% of the disk, but you can find enough free clusters within a 12% span of the disk, it would be worthwhile moving the file, often even if the number of fragments actually increases! Over time, with successive runs, files would get denser and denser.

Also, does JKdefrag assure/check that existing fragmented files are in the right order on disk, ie, as position in file increases, so does the position on disk, so the head doesn't go back and forth when reading the whole file sequentially? It would improve access times if this were assured, even if files were in more fragments.

tOM

[tOM Trottier]

It would also be useful to have a report at the end of defragmentation/optimization similar to your analysis report, eg

                           Before           After
- Number of gaps:           6038             6723
- Big gaps number:          1568              784           {don't need small gap numbers... BTW, what's "small"?}
- Big gaps total:             45.4%            99.5%
- Average gap clusters:      185.6            985.3
- Biggest gap:                 0.5784%          1.5881%
- Average density by file     97.4%            98.6%        {per file}
- Average density of disk     31.4%            44.3%        {density weighted by file size}
- Average end-begin:          20.4%            17.4%

tOM

[jeroen]

Thanks for sharing your thoughts, I appreciate it! My first reaction is that "First" and "Density" are a bit too mysterious for average users, but I will think about it. The "before and after" list is already on my wishlist for v4 of JkDefrag.

JkDefrag does not order the fragments of a fragmented file. Maybe I will add something like that to v4, but it will have a low priority because I don't really see a big need for that, sorry. It will make the fragmented file a bit faster, true, but huge files split into a few fragments have virtually no impact on performance. Small files can still be defragmented (unless the disk is completely full), so the ordering of fragments only applies to huge files. Also, if there is not enough room to fully defragment a file, then there is likely also not enough room to order the fragments.

[tOM Trottier]

Perhaps "First" should be "Starts" or "Start point"

The ordering of fragments might get important if there are lots of them and the file is read in whole. It would be worthwhile to try to maintain the order when reordering.

I'd suggest that Density is more important than totally defragging.

-tOM

[jeroen]

The ordering of fragments might get important if there are lots of them and the file is read in whole.

How can there be lot's of them? Files that are smaller than the largest gap on disk can be fully defragmented, so ordering fragments does not apply to them. Only very large files can sometimes not be defragmented, if there is not enough room on disk, and then JkDefrag will reduce the number of fragments by using the largest gaps available. And as I said before, a few large fragments have virtually no impact on performance (on reading that file). The Microsoft build-in Vista defragmenter stops at 64 megabyte and doesn't bother with larger fragments.

It would be worthwhile to try to maintain the order when reordering.

I agree. But I think reducing the number of fragments is even more important.

I'd suggest that Density is more important than totally defragging.

I disagree. Totally defragmenting is more important.

[cquinn]

a few observations (in my own opinion):

 

- used % of disk instead of clusters - who cares much about cluster details?

 Perhaps having a percentage of disk space used for spacehogs would be useful for some purposes, but cluster details are important for people who make use of other disk managment tools who like to rely on the most accurate measure of disk usage.  And who like a more accurate monitor of the changes in system files like the MFT and Journal.

Density, as a measure of the "goodness" for fragmented files, seems highly subjective to me; and we already have in place (and coming in v4) a better measure from the user perspective: Zones.
Using Zones in v3 does not appear to completely solve the problem as you describe, but you are unlikely to have a file fragmented across 45% of a disk if you have already applied -a -f and -u options as needed to defrag those particular files along with or after the rest of the disk.

Zones in v4 should allow the user to specify their own areas of greater or lesser Density by specifying the priority of their own files and folders in the defrag/optimization process. 

Edit: I do like the idea of the option to run an additonal analysis at the end of the defrag process to append to the log.

[tOM Trottier]

a few observations (in my own opinion):

 

- used % of disk instead of clusters - who cares much about cluster details?

 Perhaps having a percentage of disk space used for spacehogs would be useful for some purposes, but cluster details are important for people who make use of other disk managment tools who like to rely on the most accurate measure of disk usage.  And who like a more accurate monitor of the changes in system files like the MFT and Journal.

Sorry, my purpose in using % was to indicate where on the disk the file was going Do you know if 43564856 is near the start or end?
But I suppose a simple decimal would be better, since I mean to indicate a place rather than an amount.

Density, as a measure of the "goodness" for fragmented files, seems highly subjective to me; and we already have in place (and coming in v4) a better measure from the user perspective: Zones.
Using Zones in v3 does not appear to completely solve the problem as you describe, but you are unlikely to have a file fragmented across 45% of a disk if you have already applied -a -f and -u options as needed to defrag those particular files along with or after the rest of the disk.

While Density wouldn't matter much in sequential file access, if the file is being accessed randomly, like a database, or a large mail file, then Density would matter a great detail. Ten thousand seeks are faster over 10% of the disk than over 60%.

Perhaps V4 should allow users to name groups of filetypes (or other criteria like size), like:
 - RandomAccessFiles
 - SeldomAccessed
 - FastDiskNeeded
 - Central
or whatever the user wants.
In the analysis, the groups can be colored in the display.

Then the user can decide where to try to put them, eg:
 - Central
 - Start
 - End
 - .4 of disk
or zones.

 

Zones in v4 should allow the user to specify their own areas of greater or lesser Density by specifying the priority of their own files and folders in the defrag/optimization process. 

Edit: I do like the idea of the option to run an additional analysis at the end of the defrag process to append to the log.

[jeroen]

Perhaps V4 should allow users to name groups of filetypes (or other criteria like size), like:

Yes, different treatment per groups of files will be possible in v4 of JkDefrag, including the different colors on the screen.