What's the point of Wrap-around fragmentation?

[jeroen]

I found that if I close it during or right after the unmovable data loading step, then it "forgets" the unmovable files.

Thanks for the info, I appreciate it. I have looked at the sources and yes, that can happen. I will add a bit of code to protect against that eventuality, will be in the next release.

[poutnik]

a file fragmented due to Wrap-around fragmentation concept should not be processed by the daily script if it is sill fragmented for that reason, isn't it?

That's exactly what MyDefrag does. However, there are at least 3 reasons why things can happen as you describe.

There is still a possibility of optional wraparound concept modification:
Not to rely on unmovability, but purely on file size / wrapped gap size ratio or similar parameter.

Such wrapping would be stable.

[boco]

I'd support that, too. It doesn't matter if the data in between is movable or not (or if there even is data in between anymore), it has no influence on the reading speed of the file. To prevent leaving small gaps, MyD could even move files into the small gap that exists possibly (very often the "blocking" files are of temporary nature) to close it.

[BloodySword]

Is there a way to pause ALL write access while defragmenting? Attempts of a few bytes could be queued in RAM will defrag finished. I HATE those wrapped around files.

[Kasuha]

I HATE those wrapped around files.

I don't mind these wrapped around files, gaps in them are usually negligible. What I don't like, though, is that MyDefrag marks them as fragmented as soon as it finishes their "optimization" and moves them again the very next run.

[BloodySword]

Yes that's annoying. But I think it should be avoided instead of smudged.

[poutnik]

I think wrap around approach is good.

What is not so good is the wrapped status is conditional, making file placement unstable.
IMHO in should depend on and only on positions of file fragments and relative sizes of file and a gap ( any file or free gap ).

I think wrapping approach should be common for all fileactions, depending on global wrapping flag, in settings or in volume actions.

[BloodySword]

No. Wrapping files around is not an approach wich I understand about optimization. It is far messing up the partition.

[poutnik]

Is not better to postpone opinion until you understand ?   

Current wrapping managent implementation can lead to some partition mess.
OTOH not wrapping big files in partition with many unmovable files ( e.g. if one uses Windows EFS ) leads to a partition mess too.

[BloodySword]

But wrapping around on temporary files that are actually unknown has to be avoided!!!!
While optimizing, all write access should be redirected on the END of the partition or in RAM.
And there is no point to ague against that!

Picture this: You are about to (hand-)write a document and someone else is writing inbetween.
That's inacceptable and bold!

[poutnik]

But wrapping around on temporary files that are actually unknown has to be avoided!!!!

Why ? Yes for current implementation ... 
But if wrapping status does not depend on temporaries ?
and if wrapping is done only if appropriate to do so ?
And if done, it is taken as appropriate to keep it ?

While optimizing, all write access should be redirected on the END of the partition or in RAM.
And there is no point to ague against that!

How do you want to manage this ? Telling windows "please write for a while at partition end only or better postpone all writes" ?
It could significantly affect system performance, already partially affected by disk optimization.
And for not writing to disk for hours - without UPS ( and partially even with it ) it would be playing russion rulette.

Picture this: You are about to (hand-)write a document and someone else is writing inbetween. That's inacceptable and bold!

But it is what multitasking enviroment is about. Multiple people writing on the same paper.
I guess you are not going back to old good DOS age with exclusive access to all system resources.

[BloodySword]

But wrapping around on temporary files that are actually unknown has to be avoided!!!!

Why ? Yes for current implementation ... 
But if wrapping status does not depend on temporaries ?
and if wrapping is done only if appropriate to do so ?
And if done, it is taken as appropriate to keep it ?

Why should it be a benefit to wrap around temporary files? After deletion there are GAPS wich WILL DEGRADE PERFORMANCE!
For unmovable files, this approach is a good idea. But not for temporary files that are in the way.

While optimizing, all write access should be redirected on the END of the partition or in RAM.
And there is no point to ague against that!

How do you want to manage this ? Telling windows "please write for a while at partition end only or better postpone all writes" ?
It could significantly affect system performance, already partially affected by disk optimization.
And for not writing to disk for hours - without UPS ( and partially even with it ) it would be playing russion rulette.

A server must be paused while defragmenting. There are times where doing optimiztation or maintenance is needed.
Then a monthly defrag can be made.

But it is what multitasking enviroment is about. Multiple people writing on the same paper.
I guess you are not going back to old good DOS age with exclusive access to all system resources.

This has nothing to do with multitasking. While optimizing a system, there must not be any write access by other programs. That's my opineon.
A special file system filter could block all write access while defragmenting for example. Enabled by a SuspendOS(TillFinished) command f.e.

[Darlis]

The only solution for you would be to not optimize a volume with a running BS on it. In other words: Start the BS from CD or USB-Stick and then optimize the drive.
Then you have only a minimum amount of unmovable files and no other process is writing on the drive.

And about your ideas of implementing special optimization routines: people might think that the OS is poorly written, because it has/needs special functions to optimize. They'll more likely use an OS like Linux, that doesn't need optimization. *cough*

[BloodySword]

The only solution for you would be to not optimize a volume with a running BS on it. In other words: Start the BS from CD or USB-Stick and then optimize the drive.
Then you have only a minimum amount of unmovable files and no other process is writing on the drive.

Any tutorial how to install a minimum XP on USB-Stick or external HDD? I want to create a recovery environment with MyDefrag, Antivir and Macrium Reflect free to recover partition images.

And about your ideas of implementing special optimization routines: people might think that the OS is poorly written, because it has/needs special functions to optimize. They'll more likely use an OS like Linux, that doesn't need optimization. *cough*

Linux has to be also optimized. A reason why Linux does not get so slow is, that no user will mess his system with thausands of useless tools and programs from the internet. Another reason is that Linux uses hard- and softlinks automalicy, but MS Windows does not. So many directories could get removed if Microsoft would use this links natively.

I have only one Java Runtime Environment installation, some programs wanted to have their own in their program direcotry. I used links to point to the Oracle JRE and saved thausands of MB!!

[Darlis]

Any tutorial how to install a minimum XP on USB-Stick or external HDD?

Pe2usb: Installing Bartpe To Usb Flash Disk (English)
Bart PE PCW Edition 2 (German)

... They'll more likely use an OS like Linux, that doesn't need optimization. *cough*

Linux has to be also optimized.

Linux needs optimization? Oh my god, I didn't know that! *cough* *cough*