Thanks for the MoveToEndOfDisk

[BloodySword]

Perhaps backups images are super-spacehogs. The access to such a file is such seldom, that it is okay. The reading is sequentially so it sould not be a problem.

My Media-Files are on the beginning of D: and on the external drive. I cloned D: to the external drive as Directory-File-Structure without NTFS compression. These files are also at the beginning.

Image files wich are used very seldom such as ISO files (or other DVD/CD/BD images) for burning a DVD in the future (not mounted as CD/DVD drive!), Disk Image files, solid backup archives could be called "super-spacehogs" because they are used so seldom and are accessed sequentially, that access times doesn't matter at all.

But for you monthly standard script: What about not sorting space-hogs?

[jeroen]

Perhaps backups images are super-spacehogs.

Have you ever needed a backup? I have, several times. It is crisis time and everybody and their mother is screaming at you that you have to fix it as fast as possible. Feel free to put your backups on the slowest part of the disk if you want, but I do not want them to be any slower than they have to be.

Image files wich are used very seldom

I also have a lot of stuff that I use very seldom, probably never again. But it makes no sense to me to have fast unused empty space and slow unused image files. I want it the other way around.

But for you monthly standard script: What about not sorting space-hogs?

People expect perfect results.

[poutnik]

If considering free space as a special kind of file, all depends on relative importance of free space and spacehogs in particular partition scenario.
It can happen then significant portion of free-space-file is accessed often and need fast access.

I agree that it all depends, and I agree that free space is important for temporary files. That's why the standard scripts create a couple of gaps. I think these gaps are more than enough for the vast majority of the computers, so I do not see a need for moving the spacehogs to the end of the disk. I would agree with you if all spacehogs files were totally unused files, but files like that should be deleted or moved to offline storage. But many spacehog files are used, some of them by Windows itself, and should therefore not be placed at the very end of the disk if there is perfectly good, unused, and faster diskspace available.

It does not mean necesserily those spacehogs are not used. Only the free space can be used more often. Either because disk is full enough, or there is high free space demand.
but I agree this could be a special scenario, tailored for particular use of data partition.
E.g. if spacehogs are used once per month in average or less, and free space is rewritten several times per month.

BTW I use a special semi-spacehog zone in system partition, for spacehogs accessed last month.

[poutnik]

But for you monthly standard script: What about not sorting space-hogs?

People expect perfect results.

Unfortunately.

[BloodySword]

I tested following:

1. Restoring an disk image wich was not moved to end of disk
2. Restoring an disk image wich was moved to end of disk
3. Budning an image wich was not moved to end of disk
4. Burning an image wich was moved to end of disk

1: Took 20 Minutes
2: Took 20 Minutes, too
3: 10 Minutes and 2 Seconds
4: 10 Minutes and 28 Seconds

So therefore there is almoust no performance degration. I think it is because:

- While restoring the backup, the data is just read, decompressed and written to the drive,
the program veryfies the blocks that were actually written to the drive by re-reading them.
So the destination drive is more stressed than the source drive with the moved to end images.

- Burning does not transfer much data, because burning is still somewhat slow. I'm bruning with maximum speed,
but the drive varies it because the drive tests the media it's writing to and regulates the speed. Additionally
the "pi-effect" is ignored by image burn, so at the beginning, the writing speed is slower than at the end.

We can see, that this kind of files are accessed slowly and sequential. So I think moving them to the end of the disk is a good idea.

Because, if new files will be written to the drive or partition, then the first zone on the beginning might row. MyDefrag would have
to push the space hogs up (or with my map setting down) and this can take a long time and will extemly stress the disk.

That's the reason why I'm using this method.

I will ad following image filetypes to my non system drives scripts for those moved to end spacehogs:

Images of optical media

*.bin
*.cue
*.iso
*.isz (compressed iso)
*.img
*.sub
*.ccd
*.nrg
*.c2d
*.cdj
*.mds
*.mdf
*.bwt
*.bt5
*.bt6
*.bwa
*.bws
*.bwi
*.pdi
*.daa
*.uif
*.gi
*.ibp
*.ibq


Disk imaging

*.dcf
*.img
*.img.gz (SelfImage)
*.img.bz2 (SelfImage)
*.ima
*.tib
*.qdi
*.gho
*.ghs
*.v2i
*.dmg
*.mrimg
*.partimg
*.partimg.gz
*.partimg.bz2
*.spf
*.E01
*.wim
*.arc
*.adf

[jeroen]

So therefore there is almoust no performance degration.

It's a nice experiment. I think you are probably right about the reasons why you saw no speed difference, and I am sure you know that a measurement program such as HT Tune shows a dramatic speed difference between the beginning and end of a disk. I think your argument is that the end of the disk is fast enough for these files, and that placing them lower on the disk will make MyDefrag have to do more work. Well, be that as it may, but MyDefrag is a utility to optimize your disk, it reorganizes files so accessing them will be faster. Placing the spacehogs at the end of the disk will make them slower, and that is at complete odds with what MyDefrag is supposed to do. The running time of MyDefrag is a secondary concern, if you run the daily script every day then it does not take all that long and will not "extemly stress the disk".

[BloodySword]

Yes that is in fact a problem of adopting this as a default script. Some user might protest about this behavior.

What will happen in the DailyOptimize script, when I have VERY big spacehogs in the last zone, not on the end of the drive, when the zones above grow?
Will MyDefrag move all spacehogs or just a file from the beginning of the spacehog zone to the end of the spacehog zone?

And: When will MyDefrag show a percentage progress indicator while moving files to the end of the drive using the new method?

[jeroen]

Will MyDefrag move all spacehogs or just a file from the beginning of the spacehog zone to the end of the spacehog zone?

Not all the spacehogs, but files from the beginning to the end.

And: When will MyDefrag show a percentage progress indicator while moving files to the end of the drive using the new method?

Oeps! You have found a bug, will be fixed in the next release.

[BloodySword]

Oh, I thought it was not implemented yet because it is a completely new algorythm.
Thank you.

[poutnik]

....... but MyDefrag is a utility to optimize your disk, it reorganizes files so accessing them will be faster. Placing the spacehogs at the end of the disk will make them slower, and that is at complete odds with what MyDefrag is supposed to do. The running time of MyDefrag is a secondary concern, if you run the daily script every day then it does not take all that long and will not "extemly stress the disk".

I think optimizing of a disk can often mean to de-optimize some files, like little sacrifice for bigger global gain.
It is similar as file compression algorithms, some data structures are always bigger after compression ( by principle ).

to stress of disk - I am not sure, if daily stress multiplied by 7 times is smaller then stressing once a week.
(supposing same script, not Daily vs Weekly script )