Improvement to standard scripts

[Kasuha]

At present, standard scripts installed with MyDefrag define gaps between zone using the following commands:

    AddGap(RoundUp(ZoneEnd,VolumeFree * 0.01))

There is just one benefit to specifying the gap size this way, and it is that the less free space on the disk is there, the smaller gaps are created. However, it has also some significant disadvantages:

- it does not guarantee any minimum gap size
(if the ZoneEnd by chance falls just on the value which is divisible by 1/100 of free space, it will leave no gap)
- it does not help with zone stability
(VolumeFree is changing all the time as user and temporary files are created and deleted all the time. Rounding random variable value to another random variable value results again in random value)

This is my attempt to make it better.

In my opinion, proper gap expression should have the following properties:
1/ if the disk is not full, allow stable zones, i.e. round the boundary to fixed values
2/ if the disk is not full, gaps should not be too big
3/ if the disk is full, gaps should be shrinking with decreasing free space
4/ guarantee certain minimum gap size as workaround to FastFill() problems (with not placing files into their zones).

After some consideration, I gave up on requirement 1 (stable zones) - any rounding to fixed values may be working for many users but somebody who will get his zone oscillating right around the threshold value would end up with lots of file movement up and down every other optimization. For the fixed zones we'd need to store used values between individual script runs which is at present not possible with MyDefrag.

The result is a bit of compromise but I believe it is much better than what MyDefrag offers now:

AddGap(ZoneEnd + Minimum(VolumeFree / 100, 500 Mi))

So... gap sizes are fixed to 500 MB if there is more than 50 GB free space on the disk and they decrease proportionally to free space if there is less than 50 GB free. There is no rounding involved because it is not necessary - I believe it even leads to less average file movement as the zone boundary movement is smoother.

[BloodySword]

Great idea! I will test it now.

[RobL]

This is good.

I was using:
    AddGap(RoundUp(ZoneEnd+128MB,512MB))  // Minimum 128 MB plus align to next 512 MB boundary for stable next zone location

I then combined it with your idea, resulting in:

    AddGap(Minimum(RoundUp(ZoneEnd+256MB,512MB),ZoneEnd+VolumeFree/100))  // Minimum 256MB plus align to next 512MB boundary for stable next zone location,
                                                                          //  decreasing gap size when free space is less than 25.6GB

I think this is what I will use because my system partition is 20GB with 10GB free and I want the zones to be aligned to 512MB, even with only 10GB free:

    AddGap(Minimum(RoundUp(ZoneEnd+256MB,512MB),ZoneEnd+VolumeFree/400))  // Minimum 256MB plus align to next 512MB boundary for stable next zone location,
                                                                          //  decreasing gap size when free space is less than 6.4GB

Thanks

[RobL]

I had an error.

The last part should be:

I think this is what I will use because my system partition is 20GB with 10GB free and I want the zones to be aligned to 512MB:

    AddGap(Minimum(RoundUp(ZoneEnd+256MB,512MB),ZoneEnd+VolumeFree/18))  // Minimum 256MB plus align to next 512MB boundary for stable next zone location,
                                                                         //  decreasing gap size when free space is less than 9GB

[Kasuha]

To RobL:

Rounding the zone boundary makes it mostly stable, yes. But if the zone size is right on the boundary, you get it very unstable - based on a few kilobytes of files being deleted from or added to the zone, all the following zones might get moved by half a GB every optimization. So in average case you get the same amount of file moves anyway ... but if you're unlucky you get way more.

The only way to make this working correctly and really reduce file moves and stabilize zone boundaries is to give the system some hysteresis. That means, after I decide to move the zone by 512 MB, it requires the previous zone to lose at least 512 MB to move it back, not just a few KB. But there are no tools to do that in MyDefrag yet.

[poutnik]

To RobL:

Rounding the zone boundary makes it mostly stable, yes. But if the zone size is right on the boundary, you get it very unstable - based on a few kilobytes of files being deleted from or added to the zone, all the following zones might get moved by half a GB every optimization. So in average case you get the same amount of file moves anyway ... but if you're unlucky you get way more.

The only way to make this working correctly and really reduce file moves and stabilize zone boundaries is to give the system some hysteresis. That means, after I decide to move the zone by 512 MB, it requires the previous zone to lose at least 512 MB to move it back, not just a few KB. But there are no tools to do that in MyDefrag yet.

I remember offering hysteresis to Jeroen a time ago, but as far as I remember he is afraid it would be difficult to implement.

[Kasuha]

I remember offering hysteresis to Jeroen a time ago, but as far as I remember he is afraid it would be difficult to implement.

I believe the hysteresis could be implemented along with how currently unmovable files are stored in MyDefag.dat - it would just need to add a few variables that can be read from there by the script, changed, and saved back for the next run. Mathematic functions available in expressions could use some extension, too, to allow conditions and conditional evaluation.

In my opinion, the whole MyDefrag.dat storage could be made a bit safer if a disk identifier was used instead of just disk name. If something like that is possible it would work well even for removable drives. But I'm not sure if there is something like unique disk identifier available. I always thought there is but I'm not sure.

And of course, it's also all up to the effort Jeroen is willing to put to it.