Move data to beginning of partition

[elfring]

A defragmentation strategy "Move to end of disk" is provided. Would you also like to offer the opposite direction?

[jeroen]

All the other optimizations move files to the begin of the disk.

[elfring]

Would you like to add this detail to your documentation?

[jeroen]

Would you like to add this detail to your documentation?

It's allready there, all over the docs.

[elfring]

Would you like to offer any fine-tuning options for the defragmentation strategy "Force together"?

I would appreciate some links from option synopsis to the longer descriptions and backwards.

[elfring]

All the other optimizations move files to the begin of the disk.

It seems that it is not completely true. I see still a thinly black (empty) area for my test partition at the window's bottom.

Code:

09:03:52 Commandline argument '-a' accepted, optimizemode = 5
09:03:52 JkDefrag v3.26
09:03:52 Date: 2007/09/23
09:03:52 NtfsDisableLastAccessUpdate is inactive, using LastAccessTime for SpaceHogs.
09:03:52 Starting JkDefrag for 'D:'
09:03:52 Phase 1: Analyze
09:03:52 Phase 3: ForcedFill
09:03:53 Finished.
09:03:53 - Total disk space: 10742181888 bytes (10.00 gigabytes), 2622603 clusters
09:03:53 - Bytes per cluster: 4096 bytes
09:03:53 - Number of files: 6008
09:03:53 - Number of directories: 1170
09:03:53 - Total size of analyzed items: 7708446720 bytes, 1881945 clusters
09:03:53 - Number of fragmented items: 2, 0.03% of all items
09:03:53 - Total size of fragmented items: 147652608 bytes, 36048 clusters, 1.92% of all items, 1.37% of disk
09:03:53 - Free disk space: 2890702848 bytes, 705738 clusters, 26.91% of disk
09:03:53 - Number of gaps: 8
09:03:53 - Number of small gaps: 3, 37.50% of all gaps
09:03:53 - Size of small gaps: 24576 bytes, 6 clusters, 0.00% of free disk space
09:03:53 - Number of big gaps: 5 (62.50% of all gaps)
09:03:53 - Size of big gaps: 2890678272 bytes, 705732 clusters, 100.00% of free disk space
09:03:53 - Average gap size: 88217.25 clusters
09:03:53 - Biggest gap: 742100992 bytes, 181177 clusters, 25.67% of free disk space
09:03:53 These items could not be moved:
09:03:53   Fragments       Bytes  Clusters Name
09:03:53           3       10256         3 D:\$MFT::$BITMAP
09:03:53           1        4096         1 D:\$MFTMirr
09:03:53           1        4172         2 D:\.::$SECURITY_DESCRIPTOR
09:03:53           1      327832        81 D:\$Bitmap
09:03:53           1  3219128320    785920 D:\pagefile.sys
09:03:53   --------- ----------- --------- -----
09:03:53           7  3219474676    786007 Total
09:03:53 These items are still fragmented:
09:03:53   Fragments       Bytes  Clusters Name
09:03:53           3       16384         4 D:\Temp\~DFDB95.tmp
09:03:53           3       10256         3 D:\$MFT::$BITMAP
09:03:53          55   147635936     36044 D:\geladen\Freeware\eclipse-SDK-3.3-win32.zip
09:03:53   --------- ----------- --------- -----
09:03:53          61   147662576     36051 Total

I assume that there is enough data left from the green area that can be moved to the front to fill the unexpected gap.

[JDPower]

All the other optimizations move files to the begin of the disk.

It seems that it is not completely true. I see still a thinly black (empty) area for my test partition at the window's bottom.

That's because JKD leaves 1% free space at the start of the drive (and between zone 2 and 3).

From the homepage and docs:

A running computer will create and delete temporary files like there is no tomorrow. If the harddisk were completely optimized then the only place for new temporary files would be behind all the other data. Which is rather slow. So JkDefrag maintains a free space of 1% of the total disk space between zone 1 (directories) and zone 2 (regular files), and between zone 2 and zone 3 (space hogs).

[elfring]

I would prefer a few fine-tuning options for this free space reserve.

• Switch it off per zone
• Choose the allocation in absolute units (KB, MB ...) or in percent individually

Imagine this use case: 10 GB (2 %) space will be reserved on a 500 GB partition.
How many users would like to reuse most of this memory to shrink such a partition? Do you need more size reduction capabilities for partition resizing?[/list]

[jeroen]

• Switch it off per zone
• Choose the allocation in absolute units (KB, MB ...) or in percent individually

Both these will become possible in version 4 of JkDefrag, via the scripting language.

[elfring]

I guess that the switch-off for the reserve by the command line parameter "-f 0" is a recommended way in the meantime.

Does it accept floating point numbers?